[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...
Max
signature.asc
Description: OpenPGP digital signature