On Jun 29, 2008 20:12 +0100, Anton Altaparmakov wrote: >> 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). > > 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. The ext4 code can also have both in-inode and external xattr data. If the inode has data in both locations it will return two extents, each one with a separate set of flags. > This is the case for NTFS where > each xattr is stored as a named stream and each named stream is treated > in exactly the same way as the file data itself (which is simply an > unnamed named stream, i.e. a named stream with a filename length of zero) > thus each xattr is stored independently and depending on their sizes you > can end up with multiple xattrs inside the same on-disk block and you can > also end up with a huge xattr that has a really large number of extents > (the maximum size of each xattr/named stream in NTFS is 2^63-1 bytes > which is really rather big)... The XATTR request is really only intended for the "small" getxattr data. If there are large "xattrs" (i.e. data forks) then I'd suggest instead to use openat() to open the data fork and call FIEMAP on that directly. 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
