Re: [PATCH 16/35] union-mount: Writable overlays/union mounts documentation

[Miklos Szeredi]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/