Re: [Qemu-devel] [Qemu-block] [PATCH 2/2] qcow2: truncate the tail of the image file after shrinking the image

[Eric Blake]

On 09/21/2017 11:48 AM, John Snow wrote:
>>> Looks sane to me, but under which circumstances might we grow such a
>>> tail? I assume the actual truncate call aligns to cluster boundaries as
>>> appropriate, so is this a bit of a "quick fix" to cull unused clusters
>>> that happened to be near the truncate boundary?
>>>
>>> It might be worth documenting the circumstances that produces this
>>> unused space that will never get used. My hunch is that such unused
>>> space should likely be getting reclaimed elsewhere and not here, but
>>> perhaps I'm misunderstanding the causal factors.
>>>
>>
>> This is a consequence of how we implemented shrinking the qcow2 image.
>> (https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg04580.html)
>> But on the other hand, if we need to shrink the qcow2 image without
>> copying the data, this is the only way. The same guest offset can be
>> converted to almost any host offset in the file i.e. the first guest
>> cluster may be located somewhere at the end or the middle of the image
>> file. So we can't just take and truncate the image file on the border of
>> the truncation, therefore to shrink the image we just discard the
>> clusters that corresponds to the truncated area. The result is a
>> sparse image file where the apparent file size differs from actual size.
>> And the tail in this case is the difference between the actual size and
>> last used cluster in the image, so in fact the cutting of the tail does
>> not change the apparent file size.
>>
> 
> Oh, duh, I get it. The truncation itself creates a lot of sparseness.

It is also interesting to think about whether we should someday
implement a qcow2 defragmenting operation (either a simple one: pull all
later clusters into earlier holes, but the end result is not necessarily
contiguous; or a complex one: shuffle things so that all clusters are in
order, even though it may require moving some clusters around twice), so
that you can remove all holes from the file (perhaps useful if the file
is stored on a system that does not support holes).  But not for this
series :)

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature