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

[Eric Sandeen <sandeen@redhat.com>]

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?

> 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 is all assuming that this is not just a bog-simple "mapping only"
interface, per my other email...)

-Eric