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

Re: Extended Attributes and Access Control Lists



Hi,

On Thu, Nov 01, 2001 at 01:09:20PM +0100, Andreas Gruenbacher wrote:

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

Remember that there's a big difference between determining a VFS API
for access to fs-specific EA functionality, and a fs-internal EA
mechanism.  At the VFS level, we almost certainly want to pass in
explicit ACL requests to the fs directly, because some fs'es such as
NFSv4 or AFS don't encode ACLs over EAs.

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

It's not all that efficient --- the static allocation of inode tables
already results in a fair amount of wasted space on the disk.
Expanding the inodes only results in efficient EA support if we also
add a mechanism to allow the inode tables to grow dynamically.

Cheers,
 Stephen





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