About this list Date view Thread view Subject view Author view Attachment view

From: Jörn Engel (joern_at_wohnheim.fh-wedel.de)
Date: Wed 13 Oct 2004 - 19:50:39 BST

On Wed, 13 October 2004 11:19:31 -0700, Liam Helmer wrote:
> What immediately strikes me about the idea of COW links is that for most
> uses of it, a union mount/transparent/overlay filesystem simply works
> better. Here's what I mean:

s/most/some/. A few people argued along the same lines before and
failed to convince me. At the end of the day, unionmount failes
horribly for some scenarios I personally care about.

> 1) accounting: you can easily and transparently tell exactly how many
> files are changed from the original by looking on your overlay
> volume/directory

With the current implementation, I can do the same:
joern_at_limerick:/usr/src/kernel/linux-2.6.9-rc3-bk8$ find -links 1|wc
   4524 4524 129109

4524 files changed between 2.6.8 and 2.6.9-rc3-bk8.

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".

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.

> 2) you're not limited to having all the files on a single filesystem


> 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.

> 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.

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.

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.

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.

4) 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.

5) Unionmount has a strong sense of "original" and "copy". With
cowlinks I can copy the original, change the original and the copy
will be unaffected of the change.

> Anyways, it also strikes me that, to create full COW links will require
> porting the new file type to at least 3-4 different linux filesystems in
> order to be useful, whereas creating a union mount system that's
> filesystem independant on the VFS layer is going to be more portable,
> and _way_ more likely to be included in the mainstream kernel.

Ext[23] already support the old cowlinks, effort was minimal. I'd
port it to other filesystems as well, if I used any of them. But I
don't and I'm lazy.

Unionmount was planned by Al Viro some years ago and still isn't
finished. If Al cannot quickly hack up a sane implementation of it, I
don't consider it to be easy or even likely to be included soon.

> If I actually get to a point where I have some money to burn, this is
> one of the first things I'd put a bounty on for Linux.

Good to know. In spite of the above, I see some benefits in
unionmount and personally know someone trying to implement it.
There's a good deal of overlap both in goals and in codebase. But
cowlinks are just as poor a choice for some problems are unionmounts
are for others, so neither is going to kill the other, at least not
anytime soon.

So if you suddenly come up with money or job offers for either, please
tell me. :)


A defeated army first battles and then seeks victory.
-- Sun Tzu
Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 13 Oct 2004 - 19:50:58 BST by hypermail 2.1.3