On Tue, Oct 12, 2004 at 06:12:57PM +0200, J�rn Engel wrote:
> 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:
>
>
>
> 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.
wouldn't that sacrifice the inode is only cached
once (in the inode cache)? or is this indirect
inode similar to a symlink to the real inode?
maybe some kind of special symlink which is
inode based (not path based) and breaks/copies
on write access?
> 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 --/
so the hardlinks will form separate groups
after written to once, right? how to handle
the link count? hidden link count for C*
and separate link count for H* ?
> o Writing to any hard link will write to all hard links, as always.
but it will also break the COW link into
two segments, right?
example:
H1,H2 --> C1 --> I1
H3,H4 --> C2 --> I1
write to H3 will result in
H1,H2 --> C1 --> I1
H3,H4 --> C2 --> I2
what about link count of H1 before and after?
> 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.
sounds reasonable
TIA,
Herbert
> J�rn
>
> --
> Anything that can go wrong, will.
> -- Finagle's Law
> _______________________________________________
> Vserver mailing list
> [EMAIL PROTECTED]
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
