Re: [PATCH] Add better example about how to compress e2image raw image

[Eric Sandeen <sandeen@redhat.com>]

On 9/26/11 7:22 AM, Bernd Schubert wrote:
> On 09/24/2011 06:31 PM, Ted Ts'o wrote:
>> On Fri, Sep 23, 2011 at 05:51:24PM -0300, Carlos Maiolino wrote:
>>> On Fri, Sep 23, 2011 at 02:24:23PM -0600, Andreas Dilger wrote:
>>>> On 2011-09-23, at 12:47 PM, Carlos Maiolino wrote:
>>>>> The current example in the man page uses bzip2 to compress
>>>>> the raw image file created by the e2image, but, bzip2 does
>>>>> not honors sparse files, which causes the image to have the
>>>>> same size of the filesystem.
>>>>> Using tar together with bzip2 will make the compressed file
>>>>> to honor the sparsed file, which makes it more transportable
>>>>> than the current one if the filesystem is large.
>>
>> The problem with using tar is that it requires extra disk space by the
>> user --- somewhere a bit more than double the extra disk space
>> (because you need to have space for the hda1.e2i file before it gets
>> compressed).  For very large file systems, this can be quite
>> significant.  My general philosophy has been to make things easy as
>> possible for the users as being more important for the developers.
>>
>> For the developers, we do have contrib/make-sparse.c.  All we have to do is:
>>
>>      bunzip2<  hda1.e2i.bz2 | make-sparse hda1.e2i
>>
>> ... and this creates a sparse file in hda1.e2i.
> 
> The problem is that the bzip2 run will take a huge amount of time to
> compress all the zeros. In 2009 (with a recent CPU of that time) I
> aborted such a run for a 8TiB file system after a couple of days,
> then stored the e2image directly on disk and compressed it with tar
> and sparse support, which finished after only 12 hours... I don't
> think more modern CPUs are much faster for single threaded runs as
> bzip2 does it. So IMHO the man page should at least warn about that
> issue and suggest to use a similar tar command.

Agreed!

I think they both have their place.

passing images around in qcow format may be best in the long run though.

-Eric

> 
> Cheers,
> Bernd
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html