Re: Bug? qemu-img convert to preallocated image makes it sparse

[Max Reitz]

On 16.01.20 15:57, Eric Blake wrote:
> On 1/16/20 8:47 AM, Max Reitz wrote:
> 
>> So when you convert to the target image, you have to make sure all areas
>> that are zero in the source are zero in the target, too.  The way we do
>> that is to write zeroes to the target.  The problem is that this
>> operation disregards the previous preallocation and discards the
>> preallocated space.
>>
>> As for fixing the bug...  Can we fix it in qemu(-img)?
>>
>> We could try to detect whether areas that are zero in the source are
>> zero in the (preallocated) target image, too.  But doing so what require
>> reading the data from those areas and comparing it to zero.  That would
>> take time and it isn’t trivial.  So that’s something I’d rather avoid.
> 
> Can't we also use block status queries on the destination, as that is
> likely to be faster than actual reads and comparison to zero?

It might work for falloc preallocation, but I don’t know whether we are
really guaranteed that fallocated() areas return holes through lseek().

It won’t work for full preallocation, though.  Yes, you might get around
that with -S 0 then, but I think overall the simplest thing would be a
--target-is-zero flag.  (I don’t know, it seems useful to me in general.
 For example, when you convert to a new block device.  The biggest
drawback I see is that people might use it blindly and then complain
that their image contains garbage...)

Max

signature.asc
Description: OpenPGP digital signature