Ivan's XO Field Upgrade Proposal
Mike C. Fletcher
mcfletch at vrplumber.com
Tue Jun 26 13:10:05 EDT 2007
C. Scott Ananian wrote:
...
> Scott's comments (Ivan's not heard all of these, he might not agree):
>
...
> g) I believe that we can use "plain old" hard links when we do the
> rsync, instead of requiring any fancy vserver stuff. rsync will break
> the link appropriately when it needs to modify a file (as long as the
> --inplace option isn't given). This probably breaks a critical edge
> during development.
>
I'm not actually sure what vserver is beyond a chroot-jail-like
environment using an overlay file system, but assuming that's the basic
idea, the rationale here is that we want to allow the COW file system
overlay to be built by the rsync and only swap it into the root file
system at some later time. At the *least* after the image has been
verified!
See:
http://wiki.laptop.org/go/Union_File_Systems
for discussion of usage mechanism. Particularly the Core System
Software Tree discussion. The rsync update tree would get the update
from the server, *verify it* and only *then* add the overlay to the set
of overlays automatically booted for the system. The overlay manager
would then allow for rebooting into the overlaid file system (without
merging the update down). If all is well, the overlay is left in place
and eventually merges down into the core file-system (according to
whatever policy, but *not* immediately, as we want to allow for
roll-back if a problem is encountered a day or two after the update
(common)).
We have to keep in mind that our security patches can be a source of
problems that "brick" machines (witness Microsoft's recent problems in
China). We do *not* want to merge an update into core software images
on machines in the field without allowing the *user* to test it in
*their* circumstances!
HTH,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
More information about the Devel
mailing list