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
