Erez Zadok wrote:
In message <[EMAIL PROTECTED]>, David Quigley writes:
On Wed, 2006-07-05 at 12:39 -0400, Erez Zadok wrote:
You seem to imply that we'll detect chdir events to figure out when a user
completed typing in a series of requested changes, so that we know when to
apply them. This seems cumbersome and inefficient.
Not completely correct. The only thing that really needs to be detected
is writes to a particular file in this fs. Nothing incredibally special
is done until that final write to the branches file. Everything else is
basically setup. There is an issue of someone changing the branches and
then not updating the branches file but if they do that then its their
fault.
There's no way to guarantee that each userland write() will translate
specifically to a single ->write method in your f/s. Dirty buffers could be
cached and flushed periodically, and this increase the chance of races, if
you do a lot of small "cat" events (each of which will be an
open-write-close syscall sequence).
With a single file, presumably small, you can minimize changes b/c you'll
have [re]written the entire configuration in one shot.
Otherwise, this technique opens up a lot of races, which is why we want to
move from the individual ioctl method to a single (albeit long) remount
string. One of the problems you have to solve is atomicity: users want to
make a series of branch reconfigurations in ONE SHOT, atomically (or as
atomically as possible).
I did consider this issue of someone reading the file after someone
modified it but before it was committed and I wasn't quite sure how to
deal with it. You essentially have this problem with any psudofs unless
they commit every change to a file. You could do something along the
lines of having a file in there which is a lock and when a person wants
to modify the fs they cat something to the file (PID,1,...?) and then
its restricted to access from that person for the time being.
We have seen users of Unionfs who do a lot of branch reconfigurations in
rapid succession. So we need to be more careful than what people have done
in the past in Linux.
- we'll have to come up w/ syntax for inserting branches in the middle,
although I'd rather not complicate such a configfile too much; we can
defer such things to userland tools, who can read /unionfs/config, make
whatever changes to it, and cat it in whole back to /unionfs/config.
That seems to be the best way of doing it.
The more I think of it, the more I believe we should keep the first
implementation really really simple: when users want to make any changes,
they read in the current config, change it all they want, and then cat it
back in. That way we defer all complex add/del/insert/change ops to a
simpler userland wrapper tool, which'd be much easier to develop and debug.
why not make it a device node with commands that can be issues to it.
like an ioctl, just different (better?)
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
