linux-kernel - Re: [PATCH 01/24] Unionfs: Documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 8 Jan 2007 14:02:24 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Shaya Potter <spotter@...columbia.edu>
Cc:	"Josef 'Jeff' Sipek" <jsipek@...sunysb.edu>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	hch@...radead.org, viro@....linux.org.uk, torvalds@...l.org,
	mhalcrow@...ibm.com, David Quigley <dquigley@....cs.sunysb.edu>,
	Erez Zadok <ezk@...sunysb.edu>
Subject: Re: [PATCH 01/24] Unionfs: Documentation

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