Xuan Baldauf wrote:
>
> Hans Reiser wrote:
>
> > Xuan Baldauf wrote:
> > >
> > > It sounds sophisticated, but you know what is happening if you want to change
> > > access of some crowded directory (like "/usr", or "/home" on some systems)?
> > > Every ACL of every file within this directory gets updated...
> > >
> > > Does nobody consider dynamic inheritance? Because when accessing a file, as
> > > access of every path component needs to be checked anyway, dynamic inheritance
> > > should not pose significant overhead, but is a LOT faster for updating, and
> > > probably smarter regarding disk space. The default ACL for a file would be
> > > "inherit all rights from parent", and for files with link count = 1, this ACL
> > > metadata can be left out entirely (because it's the suggested default.)
> > > (Leaving out the ACL metadata, may result in omitting checking for access,
> > > probably making dynamic inheritance faster than static inheritance.)
> > >
> > > What do you think?
> > We agree, and just wait for the code to get written.
> >
> > Hans
>
> Tytso does not like the idea. And after some thinking about the issue, I can
> understand him. It is because
> (1) resolving from the bottom to the top might be more costly than static ACLs if no
> path component checking is needed anymore (path component checking is UNIX's
> Achilles Heel compared to NT) and
> (2) there is no definite parent for files with n_link>1
>
> But:
>
> (2) can be resolved by explicitly defining the parent or by setting the ACL in the
> directory entry rather than in stat_data
>
> (1) can be circumvented by having a (persistent) ACL change cache in reiserfs. When
> accessing a file, the cache (usually empty) is checked against wether the entry in
> the cache applies to a particular file. If the cache entries do not apply to the
> file, the files ACL is checked. This way you can always have inheriting ACLs, make
> ACL changes of millions of files atomic. (Changes place an entry in the cache, and a
> background thread changes the resolved ACL entries in every file.)
>
> Xuân. :o)
In reiser4 I contemplate the following architecture:
You have a current working plugin set which is changed by the act of cd'ing into the directory, and
that current working plugin set implements the VFS operations. It might choose to inherit the stat
data (including ACLs) from the directory for all files in that directory. This would be significant
as part of, say, implementing a 30 million file directory with 10 byte files in it (think web search
engines). With inheritance it can all fit into RAM and performance improves by an order of
magnitude because of that. To achieve extreme compression of ACLs, small files, etc., you need to
use current working plugins. The performance gain from caching less metadata in RAM is
significant. If you the user don't choose to change your current working plugins to look to the
parent directory for stat data then you don't get any change in performance or semantics.
For per file rather than per directory specified inheritance you have a flag to indicate whether you
inherit, and the key(s) of what you inherit from. I am going to hand wave here a bit in regards to
the datastructure for separately inheriting different stat data fields and file body parts from
different parents, we haven't held our v4 seminars yet (the NFS and alpha port stuff is delaying
them). In this case if you don't specify any indirections then you don't get anything different in
performance or semantics.
Only if you choose to use the feature do you get a change in performance/semantics. Assuming you
always choose to do the right thing this means you can only win. When you want to be able to change
the ACLs in one place quickly for many files, use inheritance. When accessing files that don't use
inheritance you don't have to look at any parents. Parents will likely be in cache, and accessing
them will be cheap.
Let's not get into a long discussion of this until Adamovich has finished this NFS and alpha port
crud (which he must hate, he has my sympathy), and he plus a still unhired compression specialist is
able to make real code from my vaporware.....
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:15 EST