qemu-block
[Top][All Lists]
Advanced

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

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


From: james harvey
Subject: [Qemu-block] qemu-img info ran at 100% CPU for 45 minutes without writing a byte (stopped it)
Date: Tue, 15 Jan 2019 20:15:24 -0500

In IRC, jsnow said this was a known problem, "that lseek is not
reliably fast", but requested I send this to the block list.  I used a
workaround of giving the qcow to a VM not otherwise using it, and ran
dd within the VM.  So, I don't personally need a fix, but I'm happy to
mail the list to give info to help down the bug.

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)

# ls -la /mnt/tmpqcow
-rw-r--r-- 1 root root 96636764160 Jan 15 18:50 win7.raw
# du /mnt/tmpqcow/win7.raw
0       /mnt/tmpqcow/win7.raw

Both /var/lib/libvirt/images and /mnt/tmpqcow are on the same Samsung
960 EVO NVMe (spec 1900MB/s write, 3200MB/s read.)

$ ls -la /var/lib/libvirt/images/win7.qcow2
-rw------- 1 root root 96251936768 Jan 15 18:45
/var/lib/libvirt/images/win7.qcow2

# qemu-img info /var/lib/libvirt/images/win7.qcow2
image: /var/lib/libvirt/images/win7.qcow2
file format: qcow2
virtual size: 90G (96636764160 bytes)
disk size: 90G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: true
    refcount bits: 16
    corrupt: false

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.

Starting over to get the beginning of an strace, here: https://termbin.com/misf

Running up to date Arch Linux.  Kernel 4.20.1.  qemu 3.1.0.

/var/lib/libvirt/images and /mnt/tmpqcow are on separate BTRFS
volumes, on top of LVM thin volumes.  I'll admit I'm only now seeing
that BTRFS' copy on write is being used on "/var/lib/libvirt/".  I
thought it was turned off.  This is the only VM I'm running as a qcow
or through libvirt - rest are virtio direct through qemu.

Hitting CTRL+C didn't stop qemu-img convert, I had to kill it.



reply via email to

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