Re: [Vserver] Another conceptual newbie question

On Tue, 09 May 2006 14:32:16 -0400
Fareha Shafique <fareha@eecg.toronto.edu> wrote:

> Hi,
>
> I read in one of the threads on the mailing list archive that Vservers
> use CoW. I'm having trouble understanding where, how and for what it is
> used?

the only explanation i could find for
"unification" (http://www.google.com/search?q=site%3Alinux-vserver.org+immutable+unlinkable)
on linux-vserver.org is "What is Unification (vunify)?" on
http://linux-vserver.org/some_hints_from_john. but that's rather brief for
someone unfamiliar with unix filesystem semantics, so i'll elaborate here.
someone on the list please correct me if i'm wrong. (and somebody feel free
to transfer this email or a better/correct explanation to the wiki; i'll
have spent enough time just writing this email to mess with the wiki.)

for unification (with the old utility called "vunify", and the new one
called "vhashify"), identical files (in both data and metadata, ie
ownership, privilege, etc) are hardlinked together, and marked immutable
but unlinkable. this means that a guest cannot alter the "unified" file
(because you don't want one guest altering a file and inadvertently or
maliciously altering it for all the guests), but to allow the guest to
alter the file, we allow him to unlink the file (by deleting, moving, or
copying it) which only breaks his hardlink to the "unified" file.

as an example, the following are not allowed on immutable, unlinkable files:

echo "blah blah blah" >>/bin/bash

(as this would append to the "unified" file).

instead you have:

mv /bin/bash /bin/bash.new
mv /bin/bash.new /bin/bash
echo "blah blah blah" >>/bin/bash

this usually works reasonable well, because most package managers (rpm,
dpkg) remove the old files before writing out the new files or copy the new
files on top of the old files (but they don't write the new file contents
inside the old files, trying to change the old file "in place").

but the immutable, unlinkable "unified" files can be troublesome
(especially when you accidentally unify /etc and then go to edit a
configuration file but are unexplainably denied, even as root within
the guest ;-).

so the ideal solution is copy-on-write (cow), where the kernel
automatically unlinks the file before a process writes to it. upon a
process writing to a file, the kernel will make a copy of the file
(unlinking the file) and then fulfill the process's write request. this
saves the user from having to test if a file is "unified" (immutable but
unlinkable), if so then unlinking (moving, copying, etc) it, and then
finally writing to it. the kernel will do the unlinking automatically upon
writing.

hth.

corey

-- 
undefined@pobox.com
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver