Messages in this thread | | | Date | Sun, 06 Aug 2000 23:56:34 +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 06:44:45PM +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.
For people imagining a DOS attack on filling the list: restrict the list size and make all further attempt to add an entry block.
> Is the time spent in the change-acl systemcall an issue at all? If the > user wants this to be a background task, ha can just fork, right?
People (especially Windows users) tend to wait for one action to complete until starting the next one. Imagine someone who wants to give rights to user "httpd" and then tries to access his own web pages. Or imagine (at an ISP) a (virus|mp3|*) scanning tool which should get access to 10000 customer homepages. Conventional acl changes would need hours forcing the sysadmin to idle until he|she can start test-scanning on a wide range.
Yes, you can write scripts which sequentialize tasks, and yes, you can even attach a script sequentially ( while test -e /proc/pid; do sleep 5; done; do_something_after_the_process_died ). But those approaches are limited to command line interfaces, sadly modern GUIs do not have capabilities to queue tasks into the future.
> > (Yes, I know it will not be atomic - is that an issue?)
It should not be. Making the operation atomic is just a possible side effect. (Though people might find applications for it.)
> > > -- > Ragnar Kjorstad > Torque Systems / Big Storage
Xuân. :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/
| |