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

[Andreas Dilger <adilger@Sun.COM>]

On Jun 26, 2008  15:16 +0100, Jamie Lokier wrote:
> > > 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).
> 
> I'm thinking that some filesystems won't store it as a 'blob' at all,
> but as, for example, leaves in a whole-fs tree structure on the same
> footing as permissions, size, etc.
> 
> I don't see a problem with the xattr feature - it might be useful on
> several filesystems.  (For my own program which tries to call stat()
> in disk layout order to reduce seeks, knowing xattr blocks _would_ be
> useful, as it could try to get xattrs in disk layout order too).
> 
> I just wanted to bring up that "all the xattrs of one inode" aren't
> necessarily a blob of data in the same way as ordinary contents.
> (Just in case it's being assumed that it is.)

It doesn't need to be a "blob", per se.  The physical addresses should
really represent where the xattrs are stored on disk, regardless of
whether it is stored in a separate block, or in the inode, or in the
leaves of a filesystem-wide tree.  There can be multiple blocks/extents
returned for an XATTR request (as ext4 and ext3 eventually will allow).

The logical offset of an xattr doesn't make so much sense, but I don't
think that is harmful.  I'd suggest that multiple xattrs be returned
in the order that a name search would be done, but I don't think it
really matters.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.