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), 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 (*).
This setup is likely to be useful for virtualization needs, too, but side
effects via the base directory from one node to another would render this
setup void.
Cheers,
Pete
*) The amount of administration work of any (necessary, unfortunately)
VMware XP instance running on top of those diskless clients excels that of
all diskless clients by an order of magnitude.
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
On Aug 1 2007 12:00, Hans-Peter Jansen wrote:
>
>*) The amount of administration work of any (necessary, unfortunately)
>VMware XP instance running on top of those diskless clients excels that of
>all diskless clients by an order of magnitude.
Hardly :)
Install XP, snapshot it when done. Copy .vmdk to 'all' machines.
On security upgrades, revert to snapshot (well - if the workflow allows it),
install, snapshot again. Etc.
Work: 1 1/2.
Jan
--