From: Jörn Engel (joern_at_wohnheim.fh-wedel.de)
Date: Fri 15 Oct 2004 - 13:59:56 BST
On Thu, 14 October 2004 11:06:00 -0700, Liam Helmer wrote:
> On Wed, 2004-10-13 at 20:50 +0200, Jörn Engel wrote:
>
> > But that also makes a lot of sense once you look at 2.6.7. It is a
> > copy of 2.6.6 and was copied to 2.6.7cow and 2.6.8. 2.6.6 was a copy
> > of 2.6.5, which was... Things would get messy with a big tree of
> > union mounts.
>
> OK, I can understand that use of it i.e. better ability to share space.
> For this sort of thing, of course, I'd use LVM snapshots, not union
> mounts -> different tool, which you also seem less than keen on ;)
Correct. Usually I want to have *one* filesystem per disk. Whatever
problem I have should be solved within that filesystem, not by adding
stuff on the block device layer.
LVM makes lots of sense for servers where you have lots of disks, want
to add some one year from now, replace broken or soon-broken ones and
similar. But why should I use LVM on my notebook? ;)
> > > 3) It allows you to keep your originals in a read-only state, by having
> > > them stored separately from your COW files
> >
> > Same goes for cowlinks. Copy all files to /root/backup or whereever
> > and no user will be able to delete them. Memory waste is limited to
> > the directory structure and additional inodes.
>
> What I mean is more that you can keep the entire filesystem in a read-
> only state... this has some benefits in terms of reliability with
> crashes/hackers, etc.
Make a backup. You unionmount layers will have to stay online, so you
still have the same problem as with cowlinks. Maybe not as frequently,
but since when does that matter.
> Yeah, my point is that it's easier with union mounts... not that it's
> impossible with COW links.
Matter of taste.
> I don't think that anyone would use union mounts for that setup, I've
> got different purposes behind it.
Different tools for different problems. ;)
> Correct, but I think that union mounts are generally less useful if
> you're using multiple layers -> the metaphor breaks down, especially as
> you can only write to the top layer.
See above.
> See, I like LVM, but I have different purposes in mind. For a single
> user system, it's a waste, granted. But, for virtual servers:
>
> Create a filesystem that contains your server image.
> Create an LVM snapshot of the filesystem, called version 0.2
> Bind mount the snapshot to each of your vservers.
> Mount an overlay for each vserver.
>
> Then, all the user's changes are in the overlay, and are stored
> completely independantly of the filesystem. The BIG advantage here is
> reproducibility: if I want to move that user's filesystem to another
> server, it's trivial, as it = snapshot + overlay. Also, if I have a team
> of servers all with the same snapshot, it's even easier, as I just move
> the overlay.
>
> Anyways, the general principle here is being able to commoditize the
> server, while retaining the flexibility to be able to configure and and
> patch systems as needed. Which is basically what I'm trying to do with
> StrongBox <plug,plug> ;)
Do you have a link to go with the plug?
I still have one problem with your scenario - time. Over the years,
the overlay will basically contain the complete server fs, as every
single file from the original will be replaced. So you end up with
the same situation as if you didn't have unionmount/cowlinks in the
first place.
Sure, you can update the "base" to a newer version, but then you also
get to write the update software that will move the overlay from one
base to the next.
With cowlinks you still have disk and DRAM efficiency after all
servers have been updated.
As for moving a vserver from one machine to the next, you can use one
of the below:
$ (cd $OLD_ROOT && tar cplf - .) | ssh $REMOTE "(cd $NEW_ROOT && tar xpf -)
$ rsync ...
First variant is what I usually do. Might take a while, but I usually
don't care. Second would be an optimization that should be just as
efficient (if not more) as moving the unionfs overlay. Both variants
are more flexible as the two machines don't need the same snapshot.
But then again, I'm biased. ;)
Jörn
-- A defeated army first battles and then seeks victory. -- Sun Tzu _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver