On Fri, Aug 15, 2014 at 10:29:50AM +0100, Al Viro wrote: > On Thu, Aug 14, 2014 at 07:58:56PM -0700, Luis R. Rodriguez wrote: > > > Christoph had noted that this seemed associated to the problem > > that the btrfs uses different assignments for st_dev than s_dev, > > but much as I'd like to see that changed based on discussions so > > far its unclear if this is going to be possible unless strong > > commitment is reached. > > Explain, please. Whose commitment and commitment to what, exactly? There are two folks, one is the btrfs developers, and the others are the VFS maintainers to provide proper guidance. > Having different ->st_dev values for different files on the same > fs is a bloody bad idea; why does btrfs do that at all? With the disclosure of stating that I'm new to btrfs as I see its been done to help cope with the copy on write mechanism, but I welcome btrfs folks to chime in if there other reasons this was done from an architectural point of view. Provided all reasons why this was done are clarified what we'd need then is proper guidance on what *would* be a much more reasonable strategy to do what was desired, and finally commitmen from btrfs folks to change btrfs to switch to this new agreed upon strategy. > If nothing else, > it breaks the usual "are those two files on the same fs?" tests... It would seem that those tests need more context now with copy on write, even the notion of disk space is all fucked up now, we need to think of it in terms of different possibilities that the new filesystems allow us to share data and different outcomes that could be possible. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
