Date: Tue, 7 Dec 1999 02:01:14 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Michael Schuster - TSC SunOS Germany <michael.schuster@germany.sun.com> Cc: freebsd-arch@freebsd.org Subject: Re: Extended File Attributes for FFS (request for design comments) Message-ID: <Pine.BSF.3.96.991207014936.14113F-100000@fledge.watson.org> In-Reply-To: <384CACF3.4A55658C@germany.sun.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(CC'ing this out onto the list because others have mentioned the same thing) On Tue, 7 Dec 1999, Michael Schuster - TSC SunOS Germany wrote: > Robert Watson wrote: > > > My assumption is that these attributes would be of fixed size, and a > > predetermined maximum size. > > Robert, I'm folowing this with half an ear, so to speak, so I may have > missed what I'm asking now: I don't quite see how you can get a > reasonable maximum for ACLs, seeing that you can have any number of them > for any given file (I'd wager you could say the same for other extended > attributes as well, I can't think of one just now ...). > Am I missing something elementary here? If not, I feel we might be > artificially and unnecessarily limiting ourselves before we actually get > started ... > My idea would be a kind of (type,length,value) tuple, a bit like > directory entries. Michael, The same issue came up on the #bsdcode irc channel this evening when I logged in for a bit to gather comments. The question is really whether or not extended attributes should be more or less capable. The problem with making them too strong is that you end up implementing (as you observe) something very much like the directory/file relationship. I was probably not entirely clear about how the limitation would work. I propose that there be (effectively) unlimited possible attributes for a given file/directory, as attribute names are handled via a filename off of the fs root (in the case of UFS/FFS). However, the value portion of the name=value component of the attribute would have a fixed size for each instance. So, for example, when the acl_access attribute was declared for /usr, a maximum size would be declared for any entry for any file with that attribute. My struct acl is 388 bytes, so that would make a good choice (most ACL implementations, except solaris, limit ACL entries to some fixed number of entries). For attribute capabilities, it might be 24 bytes, etc. The goal is to optimize for lookup performance on the attribute--it's acceptable to have a moderately costly setextattr, as long as getextattr is real fast, at least in the case of MAC labels, Capabilities, and ACLs. The ACLs will be hit for each vop_access(), which for directory trees can be pretty frequently. All of the attributes I'm looking at have a fixed size, which is nice. Supporting a fully-fledged file fork approach to attributes was discussed the evening, but I think there was concensus that this service is provided by the directory system already: if you want n named address spaces, you really want a directory with n files with those names, not a file with n forks. Using a fixed maximum size allows the UFS implemention to resemble the quota implementation: treat the attribute storage file as an array of fixed-size structures, and index into it based on inode number. If refcounting is desired (courtesy DCS), then you can do an indirection scheme and just store hashes in this, indirecting to some other storage file for the details. The first pass implementation will probably just store everything directly in the attribute file with the attribute name, just for simplicity and correctness. I guess the key question would be: are there any generally agreed upon legitimate applications for the use of a completely general attribute mechanism (i.e., no fixed size limit on the attribute values)? If so, then the fixed size limit (the feature that's hit on the most objections when it comes to designing a general-purpose mechanism) needs to be rethought. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991207014936.14113F-100000>