[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Extended Attributes and Access Control Lists



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.

This is also effectively an on-disk format change, which means it does
impact the currently deployed base (although granted if we do want to
make format changes, better to make them now rather than later).

If we are going to make on-disk changes for EA support, it'd probably
be a good time to consider whether there are any other changes which
you might also want to make at the same time.  Two such changes come
to mind.  

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).

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....

							- Ted





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]