Fwd: XO in-field upgrades

[C. Scott Ananian]

On 6/25/07, Christopher Blizzard <blizzard at redhat.com> wrote:
> On Mon, 2007-06-25 at 15:38 -0400, C. Scott Ananian wrote:
> > To my mind, this makes it clear that the on-wire format should be a
> > binary diff.  We could uncompress these diffs on receipt and maintain
> > a blob store as in the current proposal, but it seems much more
> > reasonable to sign, authenticate, and store the *diffs* rather than
> > the *blobs*, so that we don't need to recompute diffs when we want to
> > pass on our upgrade to a neighboring XO.
>
> It's not clear what that data means, exactly.  Do those files like this:
>
>   158 usr-bin-clamconf
>   158 usr-bin-clamdscan
>   161 usr-bin-clamscan
>   159 usr-bin-freshclam
>   162 usr-bin-sigtool
>
> Actually include binary files changes or are they just permissions
> changes?  If so you're >75x larger charge seems a little over the top
> since they wouldn't be transferred at all in Alex's case outside of the
> manifest. :)

No, they are actually 4-byte changes to each binary, buried in the
linker-generated section, presumably caused by an offset change in the
library.  I stared at this and the patches for a while.  You're
correct that most of the size of this diff is spent coding the
filename, but there is a real diff there.

There's a 60x change if you just look at the libraries.  So this
savings is definitely real.

> That being said, this is pretty compelling stuff.  I would love to see
> this done against various versions of libgklayout.so, which will
> probably be our largest offender.

If I were bored, I might indulge you. ;-)

> It also might be interesting to layer a diff system on top of what Alex
> has proposed so you could do it either way - diffs if ya got 'em, raw if
> ya don't.

That sounds suspiciously like the complexity you're afraid of.  Let's
just do diffs and call it done.
 --scott

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