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

[Valerie Aurora]

On Mon, May 10, 2010 at 02:57:36PM +0200, Miklos Szeredi wrote:
> On Thu, 29 Apr 2010, Valerie Aurora wrote:
> > On Thu, Apr 29, 2010 at 11:33:39AM +0200, Miklos Szeredi wrote:
> > > On Wed, 28 Apr 2010, Valerie Aurora wrote:
> > > > 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?
> > 
> > Sure.  The short version is that unionfs has to allocate another copy
> > of each file system structure - inode, etc. - and then keep an array
> > of the matching structures from each of the file system layers.
> 
> Let's not over-generalize the problem.  Current implementation has the
> following properties:
> 
>  a) one read-only layer and one read-write layer
>  b) for each non-directory only one of the layers is relevant
>  c) for directories both layers may be relevant
>  d) no need to go from a lower dentry or inode to an upper dentry/inode
> 
> >  Each
> > unionfs file system op copies data up and down between the unionfs
> > structures and the underlying structures, and then calls the lower
> > file system op as necessary.  Often it has to duplicate code from the
> > VFS before calling the lower file system ops.
> 
> Yep, and that can be fixed by adding better helpers to the VFS which
> do all the locking magic, etc, and are supplied with a "struct path"
> instead of a "char *".

Hm, I am thinking about your ideas.  Al did a code review a couple of
weeks ago and pointed out ways to eliminate about a third of the code
and push another good chunk down into the file system implementation.
Let me get the new version out and then we can look at pushing what's
left into VFS helper functions.

Thanks,

-VAL
--
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/