Re: [Qemu-block] qemu-img info ran at 100% CPU for 45 minutes without writing a byte (stopped it)

[Max Reitz]

On 18.01.19 16:25, Alberto Garcia wrote:
> On Wed 16 Jan 2019 02:15:24 AM CET, james harvey wrote:
> 
>> I ran:
>>
>> # qemu-img convert /var/lib/libvirt/images/win7.qcow2 -O raw
>> /mnt/tmpqcow/win7.raw
>>
>> 45 minutes later, qemu-img had been running with 100% CPU every time I
>> checked, and it had allocated the raw file, but still hadn't actually
>> written a single byte: (note the dd in the VM completed the 90GB in
>> about 8 minutes)
> 
> [...]
> 
>> After running this long, I ran strace for 15 seconds, here:
>> https://termbin.com/gg9k -- It's repeatedly running lseek with
>> SEEK_DATA and SEEK_HOLE.  The SEEK_HOLE always results in 96251936768,
>> and SEEK_DATA is different results.
> 
> It seems like the problem addressed by this patch:
> 
>    https://lists.gnu.org/archive/html/qemu-block/2019-01/msg00246.html

But that patch is rather controversial.

I don't think we've found a definitive solution for this issue yet
(other than the fact that tmpfs is basically just buggy (is I think what
we've claimed), and I think this is not the first time it was reported
for btrfs either).  I had some patches specifically for qemu-img
convert, too, but the issue there was that conversion of preallocated
qcow2 images on non-buggy filesystems got slower.  So we somehow have to
resolve that tradeoff...

Max

signature.asc
Description: OpenPGP digital signature