XO in-field upgrades

[C. Scott Ananian]

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.

Quoting from their FAQ:
(when running vhashify:) "The guest needs to be running because
vhashify tries  to figure out what files not to hashify by calling the
package manager of the guest via vserver enter.

In order for the OS cache to benefit from the hardlinking, you'll have
to restart the vservers."

Since vserver is doing file hashification anyway, it seems like it
would be a much better idea to use this rather than reinvent the
wheel.  Some other issues:
  a) we may need to be aware of which files are hardlinked where in
order to do proper updates.
  b) not clear how/if we can make updates to an entire tree atomically
  c) how/can we restart the vservers?  how important is this?

I think we need to bring in a vserver expert (ie, not me) to get these
details right at the start.

> Yeah, but you always need both sets of information to be able to
> generate them.  So you have to host full file + diff data if you want to
> host an update.

My proposal would be that XOs pass around binary diffs *only* among
themselves, and that if someone needs an older version or to leapfrog
versions, they ask the school server.  This allows XOs to cheaply host
updates in the common case.

> The nice thing about Alex's system is that you only
> have to host the file data that you're using on your system instead of
> file + diff data.  You end up using less space that way.

If you look at the numbers I just posted, file+diff is 1.3% larger
than just files.

>  If you want to
> downgrade, you have to get the files or use the vserver versions (maybe
> you could just use the old files handled by the CoW stuff to drive the
> update system - that might work pretty well!)

Now we're talking! ;-)

> Keep in mind that those "blobs" he's talking about are just files.  The
> only place where we would add binary diffs would be for individual
> files, not entire trees.  So what we're downloading today is only the
> changed files, largely for the sake of expediency and what I describe
> above for the space savings.

I have some issues with the fact that the manifest includes the entire
tree as well.  Upgrades should only include entries *changed* in the
manifest.

>   But if I have to choose
> between having something that works today with full files and saves some
> space[...]

We're only talking about a week's worth of work here so far.  I agree
that our schedule is aggressive, so let's get this right at design
time, rather than trying to fix things after implementation.
  --scott

-- 
                         ( http://cscott.net/ )