lkml.org 
[lkml]   [2000]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (reiserfs) Re: NFSv4 ACLs (was: ...ACL's and reiser...)


"Ragnar Kjørstad" wrote:

> On Sun, Aug 06, 2000 at 11:56:34PM +0200, Xuan Baldauf wrote:
> > > > P.P.S.: To the question: "What are you storing in the cache?": I store the list of
> > > > pending acl-change orders in the cache. (The word cache was quite misleading.
> > > > Sorry.)
> > >
> > > What if the data changes before your background thread have finished
> > > updating the ACLs?
> > >
> > > 1. change ACLs for /dir recursively
> > > 2. chage ACL for /dir/file
> > > 3. thread executing (1) changes ACL of /dir/file
> >
> > I knew that this question would come. So order the list of requested changes (the most
> > recent one at top, the oldest one at bottom). The background thread popps the orders
> > from the bottom, always hurrying to be in current state. The check (if the list is not
> > empty) has to work like going from top to bottom. (I say "has to work like", because you
> > can think if implementations where checking is implemented with a tree. If a match in
> > this tree is found, there should be tests wether the the inner entry (/dir/file) or the
> > outer entry (/dir) is newer.
>
> What if:
> 1. change ACLs for /dir recursively
> 2. touch /dir/file
> 3. thread executing (1) changes ACL of /dir/file

What is "touch"? (Changing atime and mtime?) If it does not change ACL state, it should not
matter. If it does, it should generate an entry in the list (but without saying that this
entry takes effect for all the members of the (possible) directory, only for the fs object
itself.) However, you might be right that atime|mtime of the files changed might not represent
the "atomic", "immediate" change of the bunch of ACLs. (3) might set atime|mtime after (2),
but is this a problem? I feel that I do not get the gist of what you think of, please clarify.
:o)
>
>
> BTW: This approach means ACL must be in directory-entry, because there
> is no way to check if the cache contains ACLdata for a specific "inode",
> just path.

You are right, at least without two-way links.

But I fear the NFSv4 only supports file-centric, not directory-centric ACLs. So this approach
and NFSv4 ACLs might be incompatible unless two-way links are used (this way, the resulting
ACL set is ACL1 OR ACL2 OR ... OR ACLn where ACLk is the ACL from the kth directory entry.)
(But if you had two-way links you could also determine if the file in question would have been
touched by the pending ACL change requests.)

>
>
> --
> Ragnar Kjorstad
> Torque Systems / Big Storage

Xuân. :o)

P.S.: Maybe Hans' solution is better. :o)



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

\
 
 \ /
  Last update: 2005-03-22 13:58    [from the cache]
©2003-2011 Jasper Spaans