On Wed, Jul 05, 2006 at 02:03:34PM -0400, 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.
Which means that we would have to buffer the whole new file until the file
gets closed. And _then_ proceed with parsing. AFAIK, the write syscall will
translate into one ->write op if the size is <= PAGE_SIZE.
> 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.
As long as the branch management code is properly locked (to prevent races)
it shouldn't be a problem.
> 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.
I'd even defer much of the complex parsing to userland. We could have:
/unionfs/
|
|------ union1/
|
|------ config (read-only file with /proc/mounts -like syntax)
|------ add (add branch special file)
|------ delete (delete mode)
|------ branch1
|
|------ dir (path to lower directory)
|------ mode (mode for the branch)
|------ remove (remove this branch
|------ branch2
|
....
I wouldn't allow users to change the config file directly, only through the
add/remove branch special files, etc.
Jeff.
--
Evolution, n.:
A hypothetical process whereby infinitely improbable events occur with
alarming frequency, order arises from chaos, and no one is given credit.
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
