From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 13 Oct 2004 - 21:29:35 BST
Hey Jörn!
On Wed, Oct 13, 2004 at 06:22:37PM +0200, Jörn Engel wrote:
> I don't completely understand all your questions. If I fail to
> properly answer them, please be a bastard and keep asking.
you asked for it! ;)
> 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.
would the following setup
H1,H2 -----> C1 --,-> I1
H3,H4,H5 --> C2 -´
(see I'm capable of ASCII art too ;)
have a) one, b) two or c) three inodes in
the inode cache after H1-H5 has been read from?
> > > 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
hmm, okay, but when would this optimization be done?
- for I2 at the time we write to it?
- when the last file handle is closed?
- by some userspace daemon who scans the fs?
> 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.
not a good idea IMHO, it might sound nice in this
example but usually things are more complicated:
- you do not update ssh but the sshd package
- the new sshd requires a new ssl
- scripts have to be run to create the new xsa key
and the fact that you do it four times is not really
an issue, provided that you can reunify the result
over all vservers (which is how it is currently done
with linux vserver's iunlink)
> 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.
mesa don't like it ;)
> > > 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.
yeah, sorry that was what I meant
> Before: C1:2, C2:2, I1:2
> After: C1:2, C2:2, I1:1, I2:1
okay, that's what I thought ...
so an open without MAY_WRITE would actually get
inode I1, where one with will get C1 or C2
or am I wrong here?
TIA,
Herbert
> 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
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver