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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
