Ok so I figured I would send an email to address concerns and interesting points.
1) I don't think I made this apparent in my initial posting so I am going to clarify some aspects of the creating of sub-directories. I had to do some work with cpusets recently so this is partially where I got the idea for this. When you create a cpuset its done in this manner. mount -t cpuset none /mnt/cpuset at this point we have created a mount point. In this point there are several files for the default cpuset that everything is run in. For the case of unionfs this would be empty since there is no "default" union. However you have the ability to mkdir in this directory which creates a cpuset named to match the directory you create. When you cd into this directory all of the files you saw one directory up in the base mount exist there. These are local copies for this particular set. I invision the same thing happening for this. When you perform a mkdir we can check to see if the parent to this new directory is the mount point. If it is we create a union directory. We can do something similar for each branch directory by hiding a value in the dentry private data to make sure that it resides under a union sub-directory. 2) Race conditions: What we really need here is transactions. However since we don't have actual transactions we need to mimic them. To do this I believe that an advisory lock in the union sub-directory is more than adequate. When a process wants to do branch manipulation they need to check the value in /unionfs/branch1/lock. The way I see this happening is that since we are not providing general open functionality for this pseudo filesystem we can make the open function have a special case to detect this lock. When a person tries to open(2) the lock file if its already being held we can return -EBUSY and the task that wants it can spin on it. This way we can make as many changes as we want and as long as people honor the lock we should be fine. You might have a problem with trusting people to honor that lock however programs such as sendmail do the same thing and it seems to be working fine. Since we are implementing transactions here we need to have some sort of journal to keep track of all of the changes we are making so we can roll them back if we run into a problem. This problem exists with a remount implementation of this functionality also so this isn't specific to this particular implementation. This is a completely different discussion which will have its own thread when we get to it. 3) Parsers in the Kernel: My main issue with the config file is that we need to place a rather large parser (larger than our current one) into the kernel. This is going to be huge and ugly and I can almost guarantee that the kernel people aren't going to like it either. After talking with some of the SELinux guys about their efforts to get something in the mainline kernel they said that there is a large push to getting things configured and exported to user-space via pseudo filesystems. This will make it harder to rationalize placing this huge parser into the kernel when there is already a large "generic" (I use that term loosely) parser already there. 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. 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. I believe that we really need a way to convey the fanout nature of the union to a person who is looking at it. There are a couple of additions that I want to make since I forgot about them initially. Obviously the branch directories need an imap entry in there. 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. Additionally one level up we can place a file that shows configurations of all unions at a glance. It also might be a good idea to place a symlink to the path in there also but it isn't clear if it is necessary right now (this can be done in the write to the path file). Another thing that no one seems to caught up on is "How do we unmount a union?". To do this is as simple as doing a rmdir union1 command. we will be able to cleanup the union as a function of removing its entry from our file system. 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. I hope this addresses some questions/concerns and also brings up more to be discussed. -- David Quigley <[EMAIL PROTECTED]> _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
