On Sun, Jun 29, 2008 at 08:12:32PM +0100, Anton Altaparmakov wrote: > On 26 Jun 2008, at 17:56, Andreas Dilger wrote: >> 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. > > But how would you return multiple xattrs if some of them are stored > inside the on-disk inode structure, some are stored in a single extent, > and some are stored in lots of extents, i.e. some have "proper", > block-aligned mappings and some don't. For xfs_bmap we don't care - we just return the extent map of the tree. i.e. you can't find out the location of an individual xattr without doing lots more filesystem specific decoding. If you have large xattrs and a fragmented tree, then you've got problems. Basically, the flag is not to indicate getting the mapping of a specific xattr, but that of the entire set of xattr data. If you know the offset and length of the xattr, then you can get it specifically, bu to do that you need to know about the internals of the filesystem.... FWIW, this is exactly the same case as getting the extent map of a directory data (I use xfs_bmap all the time for this) - you know where the blocks are, but without completely decoding the directory structure you have no idea where inside that map a given entry is. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
