Re: bmap for raw image deployment

[Colin Walters <walters verbum org>]

On Thu, May 21, 2015, at 04:08 AM, Artem Bityutskiy wrote:
> Hi Colin,
>
> I am writing you because you are behind the OSTtree project.
>
> I just wanted to point to the bmap-tools project, may be it will be
> interesting for you to use it for deploying images faster.

Interesting.  I'd seen it before but not thought about it a lot.

So...if you are in a situation where your OS is targeted for
one "device" with a fixed storage size (at least for the OS partition),
and a fixed filesystem type, I can definitely see where this would be useful.

OSTree is designed for "general purpose" use, the same as package
managers, so it won't mandate any particular filesystem or block
storage, and it's specifically intended to support a model where an OS
vendor provides pre-composed trees, and the downstream user gets
to choose filesystem and such.  This is the case with current Fedora
Atomic and Anaconda.

Obviously it could make sense to use both bmap and OSTree - maybe your OS
uses ostree for online in-os updates, but if you want to totally reset
a device, you could grab the build disk image and reflash with bmap.

One similar use case is that what gnome-continuous does
to update cached VM images is to mount using libguestfs,
then use "ostree admin pull-local".  It's interesting to compare
this to bmap because ostree only transfers objects (files) which
have changed between the two.  Here's an example output
run from that:
http://build.gnome.org/continuous/buildmaster/builds/2015/05/21/26/builddisks/output.txt

I'm sure bmap would still be notably faster than a pull-local approach,
but this circles back to the speed/flexibility distinction.  Say if your device
model can optionally support encryption, then you either have two disk images,
or one ostree/package set, and do filesystem level pulls.

I linked to bmap here now:
https://wiki.gnome.org/Projects/OSTree/RelatedProjects

So hopefully the above makes sense?  Am I missing anything?