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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
