On Tue, Jul 08, 2008 at 09:02:52AM -0400, jim owens wrote: > Here is the summary of the SYNC supporters argument: > > 1) XFS tools can't deal with delalloc. > > 2) XFS tools know returned data is crap and handle that. > > 3) XFS needs to obsolete and replace XFS specific api. > > 4) XFS tools must be recoded for #3, and already have > extensive logic for #2 to make rational decisions > with bad data... BUT it is impossible to have > the XFS tools fixed so #1 is also handled, thus > we must have the fiemap SYNC flag. > > AAARRRRRGGGG! > > Does anyone else see why I just don't freak'n get it! > > This is the truth: FIEMAP DATA IS UNSTABLE > > NEW TOOLS MUST DEAL WITH THAT INSTABILITY. Let's take step back and ask ourselves what tools will want to do with FIEMAP in the first place, shall we? As far as I know, it's basically only useful for bootloaders like lilo and to a limited extent grub (for its stage2 loader) and for debugging tools that are interested in knowing how fragmented a file might be. I cant think of any other really good uses, anyway. Someone what to enlighten me? For bootloaders, where the information is going to be stashed somewhere permanent, for those class of filesystems which might reorganize data after it has been mapped once, you need some magic file flag which nails down the file. Basically, a "don't you dare move this flag". This is implemented for reiserfs3, since it will move a file around once it has been placed on disk. However, how many filesystems beyond resierfs3 actually will move a file around on disk once it has been mapped to specific disk blocks and written to disk? Does XFS does this? I didn't think so. If it does, then for bootloaders like LILO it will also need a flag that prevents a block from being moved around. There are however plenty of filesystems (XFS, ext4, etc.) that play the delayed allocation game, where the FIEMAP information returned could change from "location not yet determined on disk" to "here's where we decided to put it on disk". And I assume that's what the SYNC flag does, right? So it's really just syntactic sugar for doing fsync; get fiemap; check to see if the an unmapped extent was still returned (due to a race condition; if so, go back and repeat the fsync and then retry the fiemap loop). So I think perhaps the talking-at-cross-purposes is that Jim is thinking about how to support filesystems that will in fact relocate file data on disk (for example, as part of an online shrink or when moving a file from one volume to another in a filesystem like advfs or btrfs), and other folks have been assuming a simpler world where data is either mapped to a location or disk or still in a delayed allocation state. In order to support filesystems where file data can move, then indeed you need the kind of userspace locking that Jim was talking about --- except what applications really need that kind of reliable information exactly where the file data blocks live on disk? Again, the only ones I can think of require utter stability, because the location will be stashed in some location for use by a bootloader, or something that needs to run before the filesystem is up and runing. So there, what is needed is out of scope of FIEMAP, and it's probably a flag which nails the file to a specific location on disk. And if such a file is present, it will prevent hot-removal of a volume from a filesystem group, and it may interfere with a hot-shrink operation --- but that's as it should be. Since otherwise, it would break the bootloader. Does this make sense? Regards, - Ted -- 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
