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. Erez. _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
