On Wed, 2006-07-05 at 12:39 -0400, Erez Zadok wrote: > 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. >
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. > 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. > 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 > This seems like a good idea also. The only thing that I would change about it is since we want to have multiple unionfs mounts your going to need the mount sub-directories that I mentioned before. Using cat to send an entire config to a file instead of making individual changes to mounts is a good idea. We can also have the other sub-directories in there if the user wants a hierarchical view of the union but make them read-only. > - 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). I intend to keep the normal mount syntax in there for a while because its perfectly usable for smaller unions. This is mainly like you said to make the large unwieldy unions easier to manage. > - 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. > Sounds like a great idea. > - 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. > I think it might be reasonable to ask the person to make all the changes they want outside of this file then cat it into the file or to open it up in an editor and when they goto save the file have it capture the write and perform all the tasks atomically. > - 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. > Since we have to reparse the file anyway and we have the old file and the new file can't we do this without special syntax? This might make things easier on us and easier to figure out so it might be worth doing. > - 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. > same as above. > - 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. > Erez. -- David Quigley <[EMAIL PROTECTED]> _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
