[ACL-Devel] FS meta information (properties/attributes/...)

[Andreas Gruenbacher]

Dear Robert,

thanks for contributing your design thoughts.

I can see a couple of problems, some of which you have already mentioned:

-- Fixed attribute size:
Allocating fixed-length records for file attributes (which you are apparently
doing) probably leads to very clear code. I don't think this is a good thing to
do, however. Attributes like ACL are inherently dynamic size. It probably is
hard to guess maximum sizes for other attributes, as well. A variable-size
attribute implementation would avoid such arbitrary implementation limits.

-- Retrieving attributes:
Retrieving multiple (all) attributes of a file is expensive. For that operation,
you have to read all attribute files. I assume attribute stores have a pattern
of access with high locality of reference. Your design maybe defeats efficient
caching and fast access (access checks will require reading at least ACL and MAC
labels; backups will require reading all attributes).

(Concerning backups: Backing up the attribute files plus the data files is
useless since you cannot guarantee which inode numbers files will be assigned to
when they are restored. This is no problem with the disk quota files, since UIDs
can be assumed constant.)

-- Defining allowed attributes:
Only root defines attribute names in your implementation. I think a file's owner
should be able to allocate user attributes (like an MD5 checksum, to stay with
your example).

Only the system itself should be able to allocate system attributes (like ACL,
Default ACL, Capabilities, etc.) To me it is not clear how you support that. I
could not find documentation on that.


> I'd love to see cross-platform portability on this interface--POSIX.1e
> doesn't cover it.  You can see a slightly dated version of the code (I
> will update it shortly) on http://www.trustedbsd.org/downloads/.  This is,
> of course, for a BSD-style UFS/FFS and VFS, but might be useful.  Also,
> the FreeBSD extattr(9), VOP_GETEXTATTR(9), VOP_SETEXTATTR(9) man pages
> cover the interface semantics in the kernel.

Robert, where can I find these man pages?

How about binary attribute values? It seems your proposed command line utilities
choke on them. Shouldn't the user interface allow attributes to be passed in/out
in an encoded form, such as a hex dump or base64?

> 3) Space for attributes relating to quotas is billed to the attribute file
> owner, not the owner of the object the attribute is attached to

It seems that needs fixing.

> 4) We can't save space by allowing identical attribute values to consume
> the same space, which is an optimization quite possible and effective with
> ACLs.  Clearly the backing file design could be modified to handle this
> through an extra level of indirection (attribute.index, attribute.value)
> but there are still limitations.

Hardly seems possible with your indexing-by-inode scheme. In my ACL code I'm
storing pointers to disk blocks in inodes directly.

> 6) The current limitation relies on a per-attribute-backing-file lock,
> which throttles access to attributes.  This is relatively easily fixable,
> as it's a property of our implementation.

I guess that's not a big problem.



Thanks,
Andreas

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher@computer.org
 Contact information: http://www.bestbits.at/~ag/
-------------------------------------------------------------------------
Linux ACL Developers List ---  http://acl.bestbits.at/acl-devel/

To unsubscribe, send a message with `unsubscribe acl-devel'
in the message body to majordomo@bestbits.at.
-------------------------------------------------------------------------