XO in-field upgrades

[Noah Kantrowitz]

C. Scott Ananian wrote:
> On 6/25/07, Christopher Blizzard <blizzard at redhat.com> wrote:
>   
>> That's going to be interesting, yeah.  You would need to teach the
>> wireless firmware about it?  How about just checking on wakeup?  Some
>> kind of wake-on-lan signal?
>>     
>
> Binding upgrade notifications to a multicast address as I previously
> proposed fixes this problem without any kind of firmware hacking.
>
>   
>> Can you explain how they are odd?  It sure would help everyone.
>>     
>
> Caveat: I'm not an expert here.  I haven't read the code, just the
> documentation.  So we can all follow along, start here:
>    http://linux-vserver.org/Paper#Unification
>    http://linux-vserver.org/Frequently_Asked_Questions#What_is_vhashify.3F
>
> Basically, copy-on-write works by running a tool ('vhashify') which
> looks for identical files in the different containers and hard links
> them together, then marks them immutable.  The copy-on-write mechanism
> works by intercepting writes to immutable files and cloning the file
> before making it writable by the container.
>   
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?).

--Noah


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.laptop.org/pipermail/devel/attachments/20070625/72365d6f/attachment.sig>