[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Extended Attributes and Access Control Lists
- From: Andreas Gruenbacher <ag bestbits at>
- To: Theodore Tso <tytso mit edu>
- Cc: "Stephen C. Tweedie" <sct redhat com>,Andrew Morton <akpm zip com au>, ext3-users redhat com
- Subject: Re: Extended Attributes and Access Control Lists
- Date: Thu, 1 Nov 2001 13:09:20 +0100 (CET)
On Tue, 30 Oct 2001, Theodore Tso wrote:
> On Mon, Oct 29, 2001 at 12:59:41PM -0700, Andreas Dilger wrote:
> > > You seem to be proposing a two-level hashing scheme here. That would be an
> > > improvement, as it would decrease the probability of collision. It would
> > > also not allow to re-hash a block as it's done now: When a single entry
> > > changes, only that entry's hash is recomputed, and then the block hash is
> > > computed from al the entry hashes. With a two-level scheme the whole block
> > > hash would have to be re-computed.
> > My idea IS a two-level hash, but it takes advantage of the fact that we
> > have already hashed the entry contents previously. This still makes
> > calculating the header hash relatively quick - we don't need to re-hash
> > all the contents, only the content of the entry that has changed (we do
> > this already to generate the entry hash), the names of all the entries,
> > and the entry hashes.
> This is certainly an improvement over the existing scheme, although it
> does make the recalculation of the header hash slower than it is
> today, because you do end up having to caluclate the has on more stuff
> than is currently being used today.
Given the small possible improvement on the one hand, and the constant
overhead on the otherhand, I don't think this approach is worth it.
> A simple one which I've been meaning to propose for some time is a
> very simple and straightforward compression technique. Given that for
> "system attributes" such as ACL EA's, you don't want the user-mode
> code to be able to directly modify such EA's, anyway, there's no real
> need to give it an ASCII name such as "$acl" or "$defacl". Why not
> just simply adopt a specialized convention where if e_name_len is
> zero, then e_name_index is treated as an 8 bit code value indicating
> the type of system attribute being used. This implies a central
> registry for assigning values to names (so for example, someone would
> have to keep a central registry of 1 meaning $acl, and 2 meaning
> $defacl, etc., but we do that today with the filesystem feature flags,
> and it's really not all *that* onerous).
That's indeed what the e_name_index field was intended for originally. I
will look into this.
> The other change, which is not quite so fully fleshed out yet, is a
> change which Stephen and I have been privately discussing, but which
> we haven't publically floated just yet, mainly because it's not been
> baked yet. The basic observation here is that the current EA sharing
> system works mainly because the main user of the EA's is the ACL
> subsystem, and most ACL's are the same across files. However, if
> other things are stored in the EA, such as security ID's for SE Linux,
> or DMAPI tags, the ability to sharing may go down to zero, in which
> case you end up using an extra disk block for every single inode, and
> that gets rather painful.
> One of the things which we've been talking about is to consider going
> to a V2 inode. There are a number of fields which we really badly do
> need to add into the ext2 inode, including subsecond resolution of
> mtime, ctime, etc., 64-bit block counts, and that means we need to
> expand the inode. If we are going to increase the inode, probably
> what we would want to do is to keep the first 256 bytes fixed, and
> then use space after that for extended attributes. So if the user
> selects 512 byte inodes, then there would be 256 bytes available for
> EA's, before you would need to spill over into a separate disk block.
> If the user selected 1024 byte inodes, then there would be 768 bytes
> available for EA's, etc. (Given that an ACL takes up at most ~250
> bytes, I suspect that 512 or 1024 byte inodes would be more than
> sufficient for most uses).
> Anyway, the V2 inode stuff is pretty blue-sky stuff at the moment, but
> I mention it simply in the context of things which we might want to
> think about doing if we want to make format changes to the EA system;
> if we're going to make format changes, we should try to make sure that
> we only make one such change....
More available space in inodes would allow very efficient storage of
attributes that are unique to inodes. I'm not sure whether ACLs would
benefit so much from that since they can be shared very efficiently.
The other thing I'd like to introduce is a more flexible approach for
handling namespaces. Currently the code for dealing with USER and SYSTEM
namespaces is somewhat messy (user attributes start with letters; system
attributes start with a $ sign). I see good reasons for two additional
namespaces: OWNER and TRUSTED.
One of the ideas was to redefine e_name_index to store the namespace;
another approach would be to introduce another field and drop the $ prefix
of system attributes instead. I'm leaning towards the latter right now.
[Date Prev][Date Next] [Thread Prev][Thread Next]