Messages in this thread | | | Date | Mon, 07 Aug 2000 00:41:56 +0200 | From | Xuan Baldauf <> | Subject | Re: (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/
| |