From: Jörn Engel (joern_at_wohnheim.fh-wedel.de)
Date: Wed 13 Oct 2004 - 17:22:37 BST
I don't completely understand all your questions. If I fail to
properly answer them, please be a bastard and keep asking.
On Wed, 13 October 2004 16:29:05 +0200, Herbert Poetzl wrote:
> On Tue, Oct 12, 2004 at 06:12:57PM +0200, Jörn Engel wrote:
>
> > 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?
New-variant cowlinks are closer to symlinks than anything else. Like
symlinks they allocate an extra inode per link. Like fast symlinks
for ext[23] they store the link information in the inode itself.
Still, don't think of it as a symlink, it's not. Close, but
different.
> > 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* ?
Cowlinks have a link count of n for n hard links to them.
The link count to the real inode could simply be ignored, but it can
also be used for optimization. It's n for n cowlinks pointing to the
inode. (Assuming no direct hard links to the file. Direct hard links
would have interesting properties as well, but they complicate things
for now.)
Doing the cow_copy on a regular file takes two steps:
1. Turn the file into a cowlink/inode aggregate.
2. Add a second cowlink to the picture.
With above ascii-art, it should look like this:
Before:
H1 -----> I1
After 1:
H1 -----> C1 -----> I1
After 2:
H1 -----> C1 ---+-> I1
H2 -----> C2 --/
I1 has a link count of 2.
Writing to H2 will cause the cowlink to be broken, so we have this:
H1 -----> C1 -----> I1
H2 -----> C2 -----> I2
So now we end up with two distinct files with no relationship
whatsoever. I1 and I2 both have a link count of 1 to reflect that
fact. Therefore we can optimize above picture a bit:
H1 -----> I1
H2 -----> I2
The cowlinks can be removed and noone will even notice. One less
inode on disk (ext[23] care more about this than other filesystems)
and a quicker lookup, nice. But it's just an optimization, so this
can be ignored for quite a while.
Going back to the direct hard link issue, Ted had some interesting use
for this. Maybe you can comment on it:
H0------------\
H1 -----> C1 --\
H2 -----> C2 ---+-> I1
H3 -----> C3 --/
H4 -----> C4 -/
Above is a scenario where four virtual servers share the same file,
each having a cowlink to it so noone steps on the others toes. File
in question is called "sshd". Now an exploit for sshd becomes known
and the developers release a security fix.
Traditionally all four servers need to get an update. This would
break all cowlinks, so space is used four times. Worse, it requires
the administrator(s) to do the update four times. Ted sees an
alternative to this.
Instead, the direct hard link "H0" can be used as a backdoor to update
all copies of sshd simultaneously and keep the space benefit.
My opinion isn't all that bright. -ETXTBSY comes to mind, along with
the general feeling of some super-root controlling that "root" is
doing. But maybe someone here likes the idea.
> > 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?
H1 doesn't have any link count. Only C* and I* do.
Before: C1:2, C2:2, I1:2
After: C1:2, C2:2, I1:1, I2:1
Jörn
-- Good warriors cause others to come to them and do not go to others. -- Sun Tzu _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver