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

From: Jörn Engel (joern_at_wohnheim.fh-wedel.de)
Date: Tue 12 Oct 2004 - 17:12:57 BST

On Fri, 8 October 2004 13:37:30 -0400, Matt Ayres wrote:
> The guy who was going to work on it disappeared. I was actually even
> willing to fund the time it took to write it :)

Disappeared isn't exactly true, although close. For the rest of this
year my time is quite limited.

As for the design, my BOFS session on the Linux Kongress didn't
attract too much interest. Ted Tso had some useful points, mainly
expressing his concerns about verious implementation details.
Real cowlinks will be more intrusive than many people would like.

Combining this with my time constraints, the current design will
continue to live for quite some time. I use it on a daily basis and
didn't hit any real problems yet, so it appears to be a decent 90%
solution. Just not the real thing yet.

For the interested, here are the two designs:

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

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.

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.


Anything that can go wrong, will.
-- Finagle's Law
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 - 11:44:13 BST by hypermail 2.1.3