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.
Another approach which might (?) be more robust, is to somehow
encode that sparseness in a single file format that can be
transported/compressed/copied w/o losing the sparseness information,
and another tool to operate efficiently on that format at the
destination, either by unpacking it to a normal sparse file or
piping it to some other process.
qcow2 :-)
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming blog:
http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)