I've been looking into implementing xattr support, but I've a couple of questions regarding how to deal with the on-disk format. --Do we want all xattrs to be dealt with using the same generic handler, or might it be worthwhile implementing a "plugin layer" to allow different xattrs to be stored differently? I can see that in the case of verifying the security on a file, the system would read the username and mode (stat-data), posix ACLs and selinux info in quick succession, so it'd be advantageous to store those contiguously. In an earlier conversation with E.Shishkin, he suggested using a stat-data plugin for xattr support, and I can see that being appropriate in the case of ACLs and SELinux contexts, but not in the more general case. -- Are there any guidelines for the layout of the internals of objects on Reiser4? It's a correctness requirement to only return the proper contents for a given prefix/xattr name. The easiest way to do this would be to just store the full xattr name in each item. Seems a bit redundant, though, given that the vast majority of xattr access will be to a couple of common attribute types (such as posix ACL and selinux). Perhaps we could do this more efficiently by having each attribute name assigned a 32-bit int, though we'd have to store a dictionary somewhere on the volume to map the full names to these short codes. Hashing the name to a fixed size int is also a possibility, though as this is a security requirement we'd have to use a cryptographic hash of significant length, which probably wouldn't save much space.. -- How to structure the item layout so fsck can cleanly tell a corrupt item from a healthy one. Thanks, DH -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
