Re: Suggestion: bmap files and bmaptool

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2013-08-13 at 17:48 +0200, Jochen Schmitt wrote:
> On Tue, Aug 13, 2013 at 04:58:16PM +0300, Artem Bityutskiy wrote:
> > Hi Fedora developers,
> 
> > $ dd if=Fedora-x86_64-19-20130627-sda.raw of=/dev/sdd
> > 4194304+0 records in
> > 4194304+0 records out
> > 2147483648 bytes (2.1 GB) copied, 799.487 s, 2.7 MB/s
> 
> 1.) Seems to be a slow USB flash drive.

Sure, typical slow, but large size and cheap USB stick most people have.

> 2.) What time did you get, if you are specify a large bs value
> on the dd command. For example
> 
> dd if=Fedora-x86_64-19-20130627-sda.raw of=/dev/sdd bs=100M

It is faster: 2147483648 bytes (2.1 GB) copied, 529.886 s, 4.1 MB/s


bmaptool is still a bit faster than dd, because it sets the I/O
scheduler to 'noop' and tweaks the queue size. It also does not hog the
system, and it reacts on Ctrl-C almost immediately, unlike dd. I
carefully took care of this.

But this all is not the point, these are additional goodies. The main
point of bmaptool is in having the bmap file, and _then_ you get real
speed-up, based on the sparseness of the original image.

Other things like reading from remote sites, progress indicator,
protecting your mounted disks, uncompressing on-the-fly, checking sha1
of the data ond of the bmap file itself - are goodies, although
important ones.

This is not of interest for people who flash once a month. This is of
interest for people who flash images more often than that, e.g., for
testing, or in a production line (not Fedora case, though, I guess).

But even for people who flash occasionally it would be nice to run only
one single command:

bmaptool copy URL-to-.xz-file /dev/my-block-device

which would do everything, very quickly (if the connectivity is not a
bottleneck), and reliably.

Check the docs if you are interested, we have rpm/deb packages, publish
tarballs, etc.

But the base principle is to utilize the inherent sparseness most raw
images have a lot of, record this in the bmap file before it is lost,
then publish the image in any form (compressed or not), and use the bmap
file for fetching the sparseness information and writing/copying only
the real data, and leaving out the zeroes.

And the larger is the image, and the more often you have to copy/flash
it, the more useful bmap file is. 

-- 
Best Regards,
Artem Bityutskiy

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux