Re: bmap for raw image deployment

[Artem Bityutskiy <dedekind1 gmail com>]

On Thu, 2015-05-21 at 08:31 -0400, Colin Walters wrote:
> 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),

Yes, just to give an example of how this idea was actually used in real
life - you are mass-producing your phone, they all have the same eMMC
(or few variants), you have a single image which your flasher deploys on
the factory. The flasher is very dumb and just writes blocks. Bmap file
tell which blocks to write.

But with a smarter flasher or the "firstboot" service one could enlarge
partitions or volumes if needed (in case the image is smaller than the
storage device).

> and a fixed filesystem type, I can definitely see where this would be useful.

Well, the file-system inside the image may be anything. The tool has
some requirements to the host file-system. The host is where you
generate the raw image.

> 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.

So it works on file-level, not block level.

I was imagining you would sometimes need to generate bootable raw
images. Raw images are those which you may dd to a device.

If that was the case, then having a bmap-file for these raw images could
be beneficial - it could allow users to deploy the images potentially
many times faster than with 'dd'. And those users who are fine with 'dd'
would not have to use it.

Thanks for looking at this!