After spending a while thinking about this I do not think that remount is appropriate for adding/removing/reordering branches. While remount seems to be the ideal way to change branch configurations the amount of data that can be passed to it seems like it will not be enough. The general trend for configuration is to use psudo filesystems. If we do not want to introduce dependencies for unionfs such as sysfs or configfs we can create our own psudofs ala selinux, cpusets, and futexes. Here is a proposed solution using a psudofs instead of remount.
Essentially what we want to do here is present two interfaces. The first interface is one which encapsulates the aspects of a union. In this case this can be a directory under the mounted Unionfs configfs. In this directory we have files that represent delete mode and debug level. Under this directory we now have sub-directories. Each of these directories represents a branch in the union (the second interface). In these directories we will have the path and its mode (ro,rw,ronfs, etc..). After all of these directories are setup and configured we now can determine the branch ordering. I think the best way to do this is going to be a file in the union which is a comma separated file which contains the names of the sub-directories in the order of their priority from left to right. One thing that I have yet to figure out is how to specify where to mount to. We have two options that I can see right now. The first is to allow the mount commands to make directories in our Psudofs. Using this we can have a mount command that functions the way it use to and have it create all the necessary entries in our Psudofs. The second option would be to use a write trigger on a special file in the union root in our Psudofs which would finally perform the mount. (contents) /unionfs | |-union1 | |- debug (18) | |- delete (all) | |- mountpoint (/mnt/unionfs) | |- branches (branch1,branch2) | |- branch1 | | - path (/n/lower/b1) | | - mode (rw) | |- branch2 | | - path (/n/lower/b2) | | - mode (ro) etc... I decided to post this to the entire list instead of keeping it internal to the Unionfs developers since this greatly affects how people use Unionfs. I want feedback from everyone who uses Unionfs from the NFS client and LiveCD users, to everyday people who are using Unionfs for simple tasks. If you have any questions or concerns about my idea please post them here. A healthy discussion on this topic is necessary to make sure we get something that is better than the current system and is useful to all who want to use Unionfs. -- David Quigley <[EMAIL PROTECTED]> _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
