On Wed, Aug 01, 2007 at 12:00:42PM +0200, Hans-Peter Jansen wrote: > Am Dienstag, 31. Juli 2007 19:00 schrieb Jan Blunck: > > On Tue, Jul 31, Josef Sipek wrote: > > > On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote: > > > > Introduce white-out support to ext2. > > > > > > I think storing whiteouts on the branches is wrong. It creates all sort > > > of nasty cases when people actually try to use unioning. Imagine a > > > (no-so unlikely) scenario where you have 2 unions, and they share a > > > branch. If you create a whiteout in one union on that shared branch, > > > the whiteout magically affects the other union as well! Whiteouts are a > > > union-level construct, and therefore storing them at the branch level > > > is wrong. > > > > So you think that just because you mounted the filesystem somewhere else > > it should look different? This is what sharing is all about. If you share > > a filesystem you also share the removal of objects. > > No. At least I don't. > > Usage case: I heavily depend on using union mounts in diskless nfs setups, > since it drops the amount of administration of many systems _near_ one. It > boils down on installing the distribution of your choice in a directory, > union mount it ro, overlayed with a node private one (doing this in initrd > on the client for several reasons), You're not sharing the rw layer so it's a different scenario, and will not have the problem I'm talking about. See my other post [1] for exact scenario where storing whiteouts on a branch would cause problems. > add a little boot and automatic setup > machinery and be done. Since all changes are persistant, any system can be > set up individually, and still mostly only one tree is needed to keep up to > date.. Being in production in an office environment since two years without > major hassle (*). Unionfs is used by many people in this way. Josef 'Jeff' Sipek. [1] http://lkml.org/lkml/2007/7/31/365 -- Intellectuals solve problems; geniuses prevent them - Albert Einstein - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
