Re: [PATCH 01/24] Unionfs: Documentation

[Andrew Morton <akpm@osdl.org>]

On Mon, 08 Jan 2007 16:30:48 -0500
Shaya Potter <spotter@cs.columbia.edu> wrote:

> On Mon, 2007-01-08 at 13:19 -0800, Andrew Morton wrote:
> > On Mon, 8 Jan 2007 14:43:39 -0500 (EST) Shaya Potter <spotter@cs.columbia.edu> wrote:
> > >  It's the same thing as modifying a block 
> > > device while a file system is using it.  Now, when unionfs gets confused, 
> > > it shouldn't oops, but would one expect ext3 to allow one to modify its 
> > > backing store while its using it?
> > 
> > There's no such problem with bind mounts.  It's surprising to see such a
> > restriction with union mounts.
> 
> the difference is bind mounts are a vfs construct, while unionfs is a
> file system.

Well yes.  So the top-level question is "is this the correct way of doing
unionisation?".

I suspect not, in which case unionfs is at best a stopgap until someone
comes along and implements unionisation at the VFS level, at which time
unionfs goes away.

That could take a long time.  The questions we're left to ponder over are
things like

a) is unionfs a sufficiently useful stopgap to justify a merge and

b) would an interim merge of unionfs increase or decrease the motivation
   for someone to do a VFS implementation?

I suspect the answer to b) is "increase": if unionfs proves to be useful
then people will be motivated to produce more robust implementations of the
same functionality.  If it proves to not be very useful then nobody will
bother doing anything, which in a way would be a useful service.


Is there vendor interest in unionfs?