Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2

[Dave Kleikamp <shaggy@linux.vnet.ibm.com>]

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