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

[Dave Chinner <david@fromorbit.com>]

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.

> > > > * 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?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com