On Wed, Jul 05, 2006 at 12:39:22PM -0400, Erez Zadok wrote: > In message <[EMAIL PROTECTED]>, David Quigley writes: > 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. Agreed. > 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).
How atomic do we want to get? Single branch operation (as we do now?) or multiple branch operations as you appear to propose? > 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: I don't think we want to use /proc. Sysfs was introduced to allow for cleanup of /proc. (Wouldn't it be nice if Linux had a /proc that's as clean as that of Solaris?) > - 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). Of course. Unless it becomes completely insane to support both, we should have them at least for some time so that users can migrate their scripts to the new interface. I would also like something like libunionfs to appear after the switch to the new method. This would be a lot like libusb (which allows developers to easily access USB device info & data from userspace without having to manually parse /sys and(?) /proc). > - 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. I like the one value per file approach a little better. (And the kernel people appear to as well: sysfs, configfs, etc.) It also greatly simplifies the parsing code in kernel - you are getting either a string or an integer. > - 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. Again, I like the sysfs "power" file idea: echo 1 > /unionfs/union1/branch2/delete > - 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. Agreed. Making userland do as much work as possible is a Good Think(tm). Jeff. -- Keyboard not found! Press F1 to enter Setup _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
