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: [EMAIL PROTECTED]:/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 True. > 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. :) J�rn -- A defeated army first battles and then seeks victory. -- Sun Tzu _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
