Suggestion: bmap files and bmaptool

Artem Bityutskiy dedekind1 at gmail.com
Mon Aug 19 11:40:58 UTC 2013


On Sat, 2013-08-17 at 17:09 +0100, Richard W.M. Jones wrote:
> On Thu, Aug 15, 2013 at 12:34:26PM -0500, Eric Sandeen wrote:
> > But then there's the issue of transporting these sparse files
> > around.  We have had the same problem in the past with large e2image
> > metadata image files, which may be terabytes in length, with only
> > gigabytes or megabytes of real data.  e2image _itself_ creates a
> > sparse file, but bzipping it or rsyncing it still processes
> > terabytes of zeros, and loses all notion of sparseness.
> 
> xz preserves sparseness.  We use it for preserving and compressing
> virt-sparsify'd images.

Right, this is a good solution for the problem area of just saving the
sparseness and later restoring it.

The problem area for bmaptool is a bit wider.

1. There are large images which are inherently sparse
2. They are distributed via ftp/http/etc servers

How do we enable the users flashing these images

a) very quickly
b) easily
c) without breaking the old way of flashing (dd)

For the first part, we exploit the sparseness information, which is
saved in the bmap file.

For the second part, we implement stream-reading directly from the
remote service, stream-decompressing on-the fly, and flashing in
parallel. This rules out the "xz saves sparseness" design.

For the third part, we keep the sparseness information in a separate
file which makes it entirely optional.


-- 
Best Regards,
Artem Bityutskiy



More information about the devel mailing list