add 18th iteration of classifier

1 files changed, 71 insertions, 0 deletions

diff --git a/results/classifier/118/none/1819343 b/results/classifier/118/none/1819343
new file mode 100644
index 000000000..2c206b4ec
--- /dev/null
+++ b/results/classifier/118/none/1819343
@@ -0,0 +1,71 @@
+ppc: 0.741
+device: 0.738
+virtual: 0.698
+architecture: 0.695
+files: 0.673
+network: 0.634
+graphic: 0.630
+semantic: 0.586
+user-level: 0.545
+performance: 0.537
+socket: 0.505
+register: 0.485
+x86: 0.478
+vnc: 0.476
+hypervisor: 0.444
+PID: 0.444
+permissions: 0.409
+debug: 0.403
+VMM: 0.391
+kernel: 0.370
+TCG: 0.365
+i386: 0.363
+boot: 0.358
+mistranslation: 0.317
+peripherals: 0.311
+risc-v: 0.303
+KVM: 0.275
+arm: 0.254
+assembly: 0.101
+
+Qcow2 image stuck as locked after host crash
+
+After a host crash, the qcow2 image of the VM, stored on a remote NFS share, has become inaccessible. Libvirt/QEMU reports that 'failed to get "write" lock\nIs another process using the image [/path/nfs/image.qcow2]?'. No process is accessing the image from either host or the network share side. There is no obvious way in qemu-img to force unlocking the file or repair the image (attempting a qemu-img check with -r all results in qemu-img complaining about the lock and being unable to do force-share=on on anything but readonly images).
+
+I'm currently attempting to fix this by converting the image via 'qemu-img convert -U -f qcow2 -O qcow2 image.qcow2 image_2.gcow2', though this will likely take some time.
+
+Using QEMU 3.1.0
+
+I wonder if your QEMU is using OFD locks or not, which might depend on a few things:
+-Are you using a distributed QEMU or one you've built yourself?
+-What glibc was it compiled against?
+-What version of Linux are you running under?
+
+I would have thought that after the process that held the lock died that the lock would be released, but perhaps it's more complicated than that because of NFS, perhaps there's a very long timeout involved somewhere?
+
+Hi,
+
+I used both the standard qemu package from the archlinux repositories as well as one I compiled myself with a few patches on top to improve audio performance.
+
+According to my logs, the compiled version used 2.28-4, I don't know what archlinux compiles them against. 2.28-5 is currently deployed on the system.
+
+The system is an up-to-date archlinux.
+
+I've unmounted and mounted the NFS during my recovery attempts, this should have released any possible lock that was being held, though since the host with qemu crashed and restarted this was more snakeoil than actually trying to fix things.
+
+fuser and lsof on the NFS host and QEMU host both showed no process holding a lock on the file.
+
+Hi, a colleague of mine has pointed out that this is a well-worn problem with nfs*v3*:
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1547095#c43
+
+Workarounds seem to involve:
+- Use v4, or
+- Use the nolock option.
+
+Does this cover your use case?
+
+Yes, it would be v3, I'll use v4 then, thanks!
+
+OK; I will be marking this as invalid to mark our belief that this is a bug in NFS and not in QEMU; please re-open if you run into additional troubles!
+