On Wed, 28 Apr 2010, Valerie Aurora wrote: > I'm sorry I have responded sooner, I've been trying to write a > detailed useful message and that turns out to be hard. I'll just > include a few of the highlights; mainly I want to say that I'd > rather do it the way you describe but when I tried it ended up even > uglier than the VFS implementation. > > I went down this road initially (do most of the unioning in a file > system) and spent a couple of months on it. But I always ended up > having to do some level of copy-around and redirection similar to that > in unionfs. I haven't looked at unionfs in a long time. Can you say something more specific about what these problems were? > One of the major difficulties that arises even when doing unioning at > the VFS level is keeping around the parent's path in order to do the > copyup later on. Take a look at the code pattern in the "union-mount: > Implement union-aware syscall()" series of patches. That's the > prettiest and most efficient version I could come up with, after two > other implementations, and it's in the VFS, at the vfs_foo_syscall() > level. I don't even know how I would start if I had to wait until the > file system op is called. On a high level I don't see a problem, the parent of every dentry can be found through ->d_parent. One issue is having to duplicate some locking and other stuff around vfs_whatever() calls. But that could be fixed by exporting suitable helpers from the VFS. Other than that I don't see any fundamental issues with union filesystems (except that they seem to grow too many features to be maintainable). Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
