On Wed, Jul 05, 2006 at 05:00:34PM -0400, David Quigley wrote: > Ok so I figured I would send an email to address concerns and > interesting points.
... > 3) Parsers in the Kernel: ... > This does not mean that we can not have a config file which I think is a > great idea. However I think that is something that should be handled > from user-space entirely and not in the kernel. We have access to many > useful tools for writing parsers in user-space. This brings up the issue > that since we are using a user-mode mechanism to configure filesystems > that we can't use the normal mount command. This has been addressed > before by the samba people and this is how they handle it, they > introduced a separate smb_mount program that allows them to do this. We > can do the same thing in writing a simple application for unionfs which > uses a user-mode library to parse the normal mount style and config file > syntax given to us by the user and apply the necessary operations to our > pseudofs. This will allow a person to mount a blank union and modify the > pseudofs with the normal mount command or use this and get the extra > functionality. Just to make this clear: mount => simple union creation unionfs_mount => script allowing for complex config file Another, albeit a more tricky way would be to pass the regular mount command an option (e.g., config=/some/file), which would cause unionfs to call a userspace helper script which would do all the parsing and echoing of options into the appropriate places (the kernel does similar things via userspace_helper() => effectively fork & exec). This would also allow for the branch configuration to be saved in /etc/fstab as it is just one option. > 4) The pseudofs in general: > As Erez pointed out we are not only dealing with new functionality but > new semantics entirely. This is why I believe that the hierarchical > structure I proposed is very important to this. Agreed. > Obviously the branch directories need an imap entry in there. Trivial to implement. This file would of course be visible if and only if imap support is compiled it. > In addition to this we might want to add another file in the union > sub-directory for each union that gives a nice view of union configuration > at a glance. This file could be in the "config" format as suggested by Prof. Zadok. Then the unionfs_mount script could parse it and do all that is necessary. > Another thing that no one seems to caught up on is "How do we unmount a > union?". unmounting is trivial. unmounting using the good ol' umount should still work. > To do this is as simple as doing a rmdir union1 command. Heh. Nice idea, but I think most people would still use umount. It has essentially the same things to do - although the rmdir way needs to do some things that are done automatically by the mount/umount syscall. > The same is done with branches also and we can > possibly update the union while removing the branch so the user doesn't > need the extra step but that isn't clear yet. Hrm. Interesting. I kind of like the more explicit: echo 1 > /unionfs/union1/branch1/remove But it is essentially the same concept. Jeff. -- Defenestration n. (formal or joc.): The act of removing Windows from your computer in disgust, usually followed by the installation of Linux or some other Unix-like operating system. _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
