C. Scott Ananian wrote: > On 6/25/07, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: >> It is worth noting we are not using vhashify or any of the other util >> scripts. The rainbow daemon sets up the chroot for each activity itself. >> We are a bit non-standard in that we are doing process-level >> containerization, instead of a more guest-OS system like many vserver >> users (most?). > > So we're manually copying (or hard linking?) files into the chroot on > every process activation? Won't this wear down our flash? (Or are > all our chroots in RAM?) How do/can we update the libraries/etc used > by the process in the container? Are services (like the proposed > upgrade daemon) chrooted as well? If so, how do upgraded files get > out of the chroot? > > Could you give me a pointer to the design docs on rainbow/etc? > --scott Design docs? We're still at the proof-of-concept phase really ;-). But yes, each chroot needs to be generated on the fly when a new activity starts (unless we do some funky magic with unionfs, which is probably not a great idea). The load of a few directory hardlinks should be minimal. Are we expecting to do online updating or will it be more of a windows-style "shut it all down then patch"?
--Noah
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
