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. 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)...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
--
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
