On Thu, 2008-06-26 at 09:15 -0500, Eric Sandeen wrote: > Dave Kleikamp wrote: > >> Firstly, most behavior-changing fm_flags have been removed. We're > >> left with SYNC and XATTR now. This is a very good thing because frankly, I > >> think fiemap should be targeted as a straight-forward and relatively > >> uncomplicated API for exposing extents as they appear on disk. Think "one > >> notch above extent-based FIBMAP replacement". There's a flip side to this - > >> 'complicated' file systems should be free to implement their own > >> complementary ioctls where there is a unique need that FIEMAP does not > >> address. Things like non-trivial device mappings, encryption specifics > >> (beyond 'this extent is encrypted'), don't belong here. > > > > Keeping the SYNC and XATTR flags seems contradictory to above statement. > > If more complicated filesystems are encouraged to implement their own > > ioctls for non-generic things, then why does the new syscall need to > > support xfs-specific things so that you can supersede its existing > > ioctl? > > I don't think either of these are xfs-specific at all. > > > Honestly, I can see XATTR used generically, even though most filesystems > > don't store the XATTR as a tree. (jfs stores it in a single extent.) > > That's fine, so, you return that one extent. I'm not sure what it has > to do with whether or not it's a tree? Okay. I'm fine with that. > > SYNC really doesn't look like it belongs, and it's only there so that > > the new ioctl acts like the xfs ioctl. > > I disagree, while it may have been inspired by the xfs behavior, it's > not at all xfs specific. > > If a filesystem implements delalloc, you may want to know which ranges > are still delalloc in the fiemap output, or you may want to put them on > disk and know the actual physical location. And if you want a snapshot > of an actual, consistent layout of the file at a point in time, then you > need an atomic sync+map - for any filesystem. This makes sense. In fact, I could see always doing the sync if there are delalloc blocks to ensure that the location of the blocks will always be returned. > (this is all assuming that this is not just a bog-simple "mapping only" > interface, per my other email...) I guess I was put off by Andreas' response that FIEMAP_FLAG_SYNC is there because xfsbmap had it "isn't harmful either". This seemed a bit weak, but I see that there is a better justification than just that. -- David Kleikamp IBM Linux Technology Center -- 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
