[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] qemu-img info ran at 100% CPU for 45 minutes without wr

From: Max Reitz
Subject: Re: [Qemu-block] qemu-img info ran at 100% CPU for 45 minutes without writing a byte (stopped it)
Date: Sun, 20 Jan 2019 23:56:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

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...


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]