On Mon, 08 Jan 2007 16:30:48 -0500 Shaya Potter <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
