In message <[EMAIL PROTECTED]>, David Quigley writes:
> To do this you would create a new sub-directory under your union and
> then proceed to cat a new string into the branch ordering file for the
> union. Here is an example of the commands
>
> cd /unionfs/union1
> mkdir branch3
> cd branch3
> echo mypath > path
> echo mymode > mode
> #echo imap info if necessary
> echo myimap > imap
> #back to our directory for our union
> cd ..
> #this line will check the current against what is being
> #written to this file to check if changes are necessary
> #and will perform the correct operations (shifting, adding,
> #deleting etc)
> echo branch1,branch3,branch2 > branches
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.
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'm not sold on this idea yet, but I do think this may be better than asking
users to craft a rather long mount-time option string. If this is the way
we go then I think a better way would be to exchange information ala /proc
files, such as /proc/partitions:
- a single special file exists under each union mount, say /unionfs/config
- if you cat the file, you get the whole union configuration. Each line is
a single branch. Top line is leftmost branch (highest priority). Each
line is whitespace delimited: branch dir name, flags/mode, imap options,
etc.
- the file can start empty if you mounted a blank unionfs (assuming we want
to allow that)
- to make life easier for existing users, we may want to keep the existing
mount options supported (at least for some time, or maybe indefinitely).
- to make it easier for people to import a whole configuration option set,
we should support a new mount option such as:
# mount -t unionfs -o configfile=/etc/unionfs.mount.options
That configfile format should be identical to /unionfs/config, so you can
even *create* /etc/unionfs.mount.options by
# cat /unionfs/config > /etc/unionfs.mount.options
(after having setup the individual branches manually -- similar to
iptables-save/restore).
- the /unionfs/config file's output should not be pretty-printed for people
to read, but designed to be easily parseable and produced by automated
programs.
- Now, if someone wants to change an individual branch's configuration, they
would have to cat the whole line for that branch, into /unionfs/config.
Similarly, if they want to change two or more, they can do so individually
-- or, if they want it to be done atomically, they can cat the whole three
lines into /unionfs/config.
- if we want, we can offer special semantics on how to delete individual
branches. For example, you could cat the branch's name w/o any
flags/mode, or echo it with a "-" in front.
- we could also think up syntax for deleting all branches: maybe we can trap
->unlink() on the file. Or maybe cat a special keyword "-ALL" first.
- 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.
Erez.
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
