From: Liam Helmer (linuxlists_at_thevenue.org)
Date: Thu 14 Oct 2004 - 19:06:00 BST
On Wed, 2004-10-13 at 20:50 +0200, Jörn Engel wrote:
> The only problem is that cowlinks are symmetric. There is no natural
> way to tell the "original" from the "copy". It's up to the user to
> declare 2.6.8 the "original" and 2.6.9-rc3-bk8 the "copy".
This is one thing that I live about Union mounts, is that the layers are
completely distinct.
> 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 ;)
> > 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.
> > 4) Easy to integrate with quotas so you can limit how much space can be
> > taken up by COW files
>
> Not sure. With cowlinks, it's easiest to account full filesize for
> all owners of a cowlink. Of course, cowlinks save space so you can
> start the overcommit game, but that's up to the admin to decide.
Yeah, my point is that it's easier with union mounts... not that it's
impossible with COW links.
> Ok, here is my list of unionmount problems:
>
> 1) Mounting requires root privileges. Cowlinks are useful for anyone,
> why limit them to root? And if you need a suid-root wrapper so let
> everyone have them, welcome to security hell.
Yes... this is a drawback.
> 2) My normal cowlink setup would require a tree of ~20 union mounts.
> Remember to do them in the correct order or things will go boom.
I don't think that anyone would use union mounts for that setup, I've
got different purposes behind it.
> 3) I can pull a drive from my notebook, insert it into the next, boot
> and have the full cowlink tree. With union mounts, I'd also have to
> replicate the mount script, because without the correct order things
> will go boom.
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.
> [with cowlinks] All files end up on the same filesystem. I don't have to
> repartition my drive because one of the 20 partitions ended up being
> too small. I don't have 10GB of free space accumulating over all the
> partitions. I don't have to deal with LVM to avoid above problems.
> And even with LVM, I'd still have the problem that ext3 doesn't allow
> online resizing yet. And if it did, I'd constantly copy my
> filesystems around for no good reason at all.
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> ;)
> So if you suddenly come up with money or job offers for either, please
> tell me. :)
Will do ;)
Cheers,
Liam
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver