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