Ivan's XO Field Upgrade Proposal

[Mike C. Fletcher]

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