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

[Eric Sandeen <sandeen@redhat.com>]

Dave Chinner wrote:
> On Thu, Jun 26, 2008 at 01:19:51PM +0100, Jamie Lokier wrote:
>> Andreas Dilger wrote:
>>>> Is there a reason why fsync() before calling FIEMAP is unsuitable?
>>> This was added because the xfsbmap operation always did an fsync before
>>> returning the extents.  I don't think it is strictly required, but it
>>> isn't harmful either.
>> It's not harmful but suggests it might do something important -
>> e.g. provide atomicity between the fsync and getting extends.
> 
> It does precisely that.

xfs does via the bmap ioctl, but the generic fiemap implementation does
not.  It probably should be removed from the vfs level:

+	if (fieinfo.fi_flags & FIEMAP_FLAG_SYNC)
+		filemap_write_and_wait(inode->i_mapping);

and let the filesystem handle it in an atomic way?

>>>>> * FIEMAP_FLAG_XATTR
>>>>> If this flag is set, the extents returned will describe the inodes
>>>>> extended attribute lookup tree, instead of it's data tree.
>>>> What is this for?  The meaning of the xattr tree sounds rather
>>>> filesystem specific to me.
>>> This is to return the location of the xattr blocks for the inode.
>> Some filesystems will store xattrs as metadata - in exactly the same
>> as, say, the inode itself, it's permissions, mappings etc.
>>
>> I'm not sure why xattrs get special treatment, compared with a
>> hypothetical FIEMAP_FLAG_METADATA for example, indicating which
>> physical blocks contain the inode itself, or it's other auxiliary
>> information.
> 
> Because xattrs tend to contain user data, not metadata?

Agreed, I don't see anything particularly strange about returning the
xattr mapping, and to me it's not particularly fs specific  (well, the
detailed format of the on-disk data might be, i.e. the layout of names &
values within that blob of data, but it is still user data... I guess
it's something of a grey area).

-Eric