On Tue, 09 May 2006 14:32:16 -0400 Fareha Shafique <[EMAIL PROTECTED]> 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 -- [EMAIL PROTECTED] _______________________________________________ Vserver mailing list [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
