Messages in this thread | | | Subject | Re: [Ext2-devel] [PATCH 1/2] ext2/3: Support 2^32-1 blocks(Kernel) | From | "Stephen C. Tweedie" <> | Date | Mon, 27 Mar 2006 14:55:01 -0500 |
| |
Hi,
On Sat, 2006-03-25 at 11:51 -0300, cascardo@minaslivre.org wrote:
> Regarding compatibility, there are plans to support xattr in Hurd and > use them for these fields, translator and author. (I can't recall what > i_mode_high is used for.) With respect to that, I'd appreciate if > there is a recommendation to every ext2 implementation (not only > Linux) that supports xattr, to support gnu.translator and gnu.author > (I'll check about the i_mode_high and post about it asap.).
What do you mean by "support", exactly?
There are 3 different bits of xattr design which matter here. There's the namespace exported to users via the *attr syscalls; there's the encoding used on disk for those different namespaces; and there's the exact semantics surrounding interpretation of the xattr contents.
Now, a non-Hurd system is not going to have any use for the gnu.* xattr semantics, as translator is a Hurd-specific concept. The user "gnu.*" namespace is easy enough to teach to Linux: to simply reserve that namespace, without actually implementing any part of it, I think it be sufficient simply to claim the name in include/linux/xattr.h.
For ext2/3, though, the key is how to store gnu.* on disk. Right now the different namespaces that ext* stores on disk are enumerated in
fs/ext[23]/xattr.h
which, for ext2, currently contains:
/* Name indexes */ /* Name indexes */ #define EXT2_XATTR_INDEX_USER 1 #define EXT2_XATTR_INDEX_POSIX_ACL_ACCESS 2 #define EXT2_XATTR_INDEX_POSIX_ACL_DEFAULT 3 #define EXT2_XATTR_INDEX_TRUSTED 4 #define EXT2_XATTR_INDEX_LUSTRE 5 #define EXT2_XATTR_INDEX_SECURITY 6
If you want to reserve a new semantically-significant portion of the namespace for use in the Hurd by gnu.* xattrs, then you'd need to submit an authoritative Linux patch to register a new name index on ext2; reservation of such an xattr namespace index is in effect an on-disk format decision so needs to be agreed between implementations.
> Regarding userland tools, it would be wise if they would still support > old format filesystems, including those with fs creator set to > Hurd. That would include supporting the oob block for translator when > counting used/free blocks and other operations like copying a file > using debugfs, for example.
Certainly; I don't think anybody is arguing against that, and I regard such backwards compatibility as an absolute requirement.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |