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

From: Liam Helmer (linuxlists_at_thevenue.org)
Date: Wed 13 Oct 2004 - 19:19:31 BST


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:

1) accounting: you can easily and transparently tell exactly how many
files are changed from the original by looking on your overlay
volume/directory
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
4) Easy to integrate with quotas so you can limit how much space can be
taken up by COW files

There's a few partial implementations of this around, but none of them
work work in a sense that can be used for production with linux-vserver,
at least last I checked. I know Herbert pointed me to a WIKI he put up a
while ago... I can't find the link though.

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.

That's just my two cents...
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.

Cheers,
Liam

> Current:
> o All cowlinks to a file share the same inode.
>
> o Hard links and cowlinks are mutually exclusive.
>
> o A flag is used to distinguish between cowlinks and hardlinks.
>
> o Any tool written to handle hard links also works with cowlinks. In
> particular "cp -lr" can be used to copy a directory structure.
>
> o Cowlink flags exists for regular files and directories.
>
> o For regular files, see above.
>
> o For directories, it controls whether newly created files inside
> the directory have the cowlink flag set.
>
> o Currently it is possible to explicitly disable the cowlink flag on
> a file or directory below a cowlink directory. But someone
> (forgot the name) at the BOFS session pointed out that noone
> really needs this, so I should change the path_walk code to set
> the flag for any children if it's direct parent already has it
> set.
>
> o Most of the code is gone, but whenever the kernel is unsure whether
> an operation involving cowlinks is safe or not, it just fails.
> Rationale is that a non-working operation is better than silent
> corruption. Didn't trigger such a code path in quite a while.
>
> o By being special hard links, diff doesn't waste any time to compare
> two cowlinks to the same file. Same goes for a few other tools.
>
>
>
> Future:
> o Cowlinks are inodes that point to inodes.
>
> o Cowlinks can have several hard links. This is somewhat confusing,
> so let me give an example with I1 and I2 as inodes, C1 and C2 as
> cowlinks and H1 and H2 as hard links:
> H1 ---+-> C1 ---+-> I1
> H2 --/ C2 --/
>
> o Writing to any hard link will write to all hard links, as always.
>
> o Writing to any cowlink will copy the underlying inode, point the
> cowlink to the new inode and write to that.
>
> Writing to H1 in above example will satisfy both rules:
> H1 ---+-> C1 -----> I2
> H2 --/ C2 -----> I1
>
> H1 and H2 still point to the exact same files, as hard links are
> supposed to do. C1 and C2 point to completely different files, as
> cowlinks are supposed to do after a write.
>
> o Cowlinks are implemented by creating a new filetype.
>
> o stat() will hide the new filetype from userspace. Files will appear
> to be regular files.
>
> o A new syscall should be introduced to retrieve the inode number of
> the underlying inode (eg I1 in the example). Diff needs to use this
> system call so it's optimization for hard links works with cowlinks
> as well.
>
>
>
> Identical parts of both designs:
> o Copying is done on open(2) system call.
>
> o COW is done on file granularity. Page granularity may have some
> advantages, but I leave the implementation to a curious reader.
>
> Jörn
>

-- 
Liam Helmer <linuxlists_at_thevenue.org>

_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver


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:19:47 BST by hypermail 2.1.3