In message <[EMAIL PROTECTED]>, Josef Sipek writes: > On Wed, Jul 05, 2006 at 12:39:22PM -0400, Erez Zadok wrote:
> > 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? Multi-branch of course: that's the whole point we're considering remount. Under heavy loads, it's way too risky/racy to force users to apply branch changes one at a time. With the simple idea of cat'ing a whole new/revised config, users will have the ability to apply one or more changes at once, as they desire. > > 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?) I wasn't suggesting we use /proc, but that we model the format of the file after some of the /proc files -- we'll have our own special named file instead. > 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). Yes, sounds good. Besides, at some point we're going to have to split the sources into a "kmod" kernel module package and a "unionfs-utils" userland package. Erez. _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
