add 18th iteration of classifier

1 files changed, 136 insertions, 0 deletions

diff --git a/results/classifier/118/none/1621 b/results/classifier/118/none/1621
new file mode 100644
index 000000000..b8a14a0fd
--- /dev/null
+++ b/results/classifier/118/none/1621
@@ -0,0 +1,136 @@
+KVM: 0.520
+virtual: 0.504
+mistranslation: 0.483
+risc-v: 0.480
+peripherals: 0.478
+permissions: 0.475
+TCG: 0.468
+user-level: 0.457
+ppc: 0.457
+hypervisor: 0.446
+VMM: 0.444
+debug: 0.442
+performance: 0.442
+vnc: 0.437
+x86: 0.436
+device: 0.433
+register: 0.433
+boot: 0.431
+graphic: 0.428
+i386: 0.417
+assembly: 0.416
+arm: 0.409
+semantic: 0.401
+PID: 0.400
+architecture: 0.398
+kernel: 0.383
+socket: 0.378
+files: 0.376
+network: 0.341
+
+QCOW2 image grows over 110% of its virtual size
+Description of problem:
+Follow-up of https://github.com/oVirt/vdsm/issues/371
+
+As oVirt divides a iSCSI LUN into a LVM device and each VM disk is a Logical Volume, the qcow2 images are inside a LV.
+This works fine, and oVirt allows the LV to grow to 110% of its virtual size.
+
+Now we have like 1 time each month the issue that a VM tries to grow over its 110% limit, which should never happen.
+Steps to reproduce:
+1. When it happend in production, I copied the LV via dd to some file.
+2. I copied the file to a new LV on a test machine, and created a VM for it
+3. Start the VM
+4. Issue reoccurs directly
+Additional information:
+So I started some gdb'ing on the pid, and this it what seems to happen:
+```
+#16 0x0000563c60921f25 in qcow2_add_task (bs=bs@entry=0x563c62bb8090, pool=pool@entry=0x0, func=func@entry=0x563c60924860 <qcow2_co_pwritev_task_entry>, subcluster_type=subcluster_type@entry=QCOW2_SUBCLUSTER_UNALLOCATED_PLAIN, host_offset=17718824960, offset=offset@entry=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=0, l2meta=0x7f84c401c600)
+    at ../block/qcow2.c:2249
+        local_task = {task = {pool = 0x0, func = 0x563c60924860 <qcow2_co_pwritev_task_entry>, ret = 0}, bs = 0x563c62bb8090, subcluster_type = QCOW2_SUBCLUSTER_UNALLOCATED_PLAIN, host_offset = 17718824960, offset = 15192346624, bytes = 1310720, qiov = 0x7f84c4003a70, qiov_offset = 0, l2meta = 0x7f84c401c600}
+        task = 0x7f82bafffb00
+#17 0x0000563c609225b7 in qcow2_co_pwritev_part (bs=0x563c62bb8090, offset=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=0, flags=<optimized out>) at ../block/qcow2.c:2645
+        s = 0x563c62bbf990
+        offset_in_cluster = <optimized out>
+        ret = <optimized out>
+        cur_bytes = 1310720
+        host_offset = 17718824960
+        l2meta = 0x7f84c401c600
+        aio = 0x0
+#18 0x0000563c6090395b in bdrv_driver_pwritev (bs=bs@entry=0x563c62bb8090, offset=offset@entry=15192346624, bytes=bytes@entry=1310720, qiov=qiov@entry=0x7f84c4003a70, qiov_offset=qiov_offset@entry=0, flags=flags@entry=0) at ../block/io.c:1248
+        drv = 0x563c6125fb20 <bdrv_qcow2>
+        sector_num = <optimized out>
+        nb_sectors = <optimized out>
+        local_qiov = {iov = 0x563c6125fb20 <bdrv_qcow2>, niov = 8192, {{nalloc = 4096, local_iov = {iov_base = 0x563c62bb8090, iov_len = 0}}, {__pad = "\000\020\000\000\000\000\000\000\220\200\273b", size = 0}}}
+        ret = <optimized out>
+        __PRETTY_FUNCTION__ = "bdrv_driver_pwritev"
+#19 0x0000563c60905872 in bdrv_aligned_pwritev (child=0x563c647f3c10, req=0x7f82bafffe30, offset=15192346624, bytes=1310720, align=<optimized out>, qiov=0x7f84c4003a70, qiov_offset=0, flags=0) at ../block/io.c:2122
+        bs = 0x563c62bb8090
+        drv = 0x563c6125fb20 <bdrv_qcow2>
+        ret = <optimized out>
+        bytes_remaining = 1310720
+        max_transfer = <optimized out>
+        __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev"
+#20 0x0000563c6090622b in bdrv_co_pwritev_part (child=0x563c647f3c10, offset=<optimized out>, offset@entry=15192346624, bytes=<optimized out>, bytes@entry=1310720, qiov=<optimized out>, qiov@entry=0x7f84c4003a70, qiov_offset=<optimized out>, qiov_offset@entry=0, flags=flags@entry=0) at ../block/io.c:2310
+        bs = <optimized out>
+        req = {bs = 0x563c62bb8090, offset = 15192346624, bytes = 1310720, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 15192346624, overlap_bytes = 1310720, list = {le_next = 0x7f829c6c8e30, le_prev = 0x7f82a3fffe60}, co = 0x7f84c4004210, wait_queue = {entries = {sqh_first = 0x0, sqh_last = 0x7f82bafffe78}}, waiting_for = 0x0}
+        align = <optimized out>
+        pad = {buf = 0x0, buf_len = 0, tail_buf = 0x0, head = 0, tail = 0, merge_reads = false, local_qiov = {iov = 0x0, niov = 0, {{nalloc = 0, local_iov = {iov_base = 0x0, iov_len = 0}}, {__pad = '\000' <repeats 11 times>, size = 0}}}}
+        ret = <optimized out>
+        padded = false
+        __PRETTY_FUNCTION__ = "bdrv_co_pwritev_part"
+#21 0x0000563c608f71e0 in blk_co_do_pwritev_part (blk=0x563c648183c0, offset=15192346624, bytes=1310720, qiov=0x7f84c4003a70, qiov_offset=qiov_offset@entry=0, flags=0) at ../block/block-backend.c:1289
+        ret = <optimized out>
+        bs = 0x563c62bb8090
+```
+
+There is a write from the VM with size 1310720 on offset 15192346624.
+A host offset is calculated for this, but this offset is 17718824960 !!
+The image/LV is only 17716740096, and 17716740096 < 17718824960 -> ENOSPC error is triggered.
+
+The code for calculating the host offset seems to be untouched for the last years.
+But it seems like for some reason it takes some offset way beyond the virtual size boundaries.
+
+The qemu-img output:
+```
+# qemu-img info /dev/mapper/test-xxxxx 
+image: /dev/mapper/test-xxxxx
+file format: qcow2
+virtual size: 15 GiB (16106127360 bytes)
+disk size: 0 B
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    bitmaps:
+        [0]:
+            flags:
+                [0]: in-use
+                [1]: auto
+            name: 428fae80-3892-4083-9107-51fb76a7f06b
+            granularity: 65536
+        [1]:
+            flags:
+                [0]: in-use
+                [1]: auto
+            name: 51ccd1fc-08a4-485d-8c04-0eb750665e05
+            granularity: 65536
+        [2]:
+            flags:
+                [0]: in-use
+                [1]: auto
+            name: 19796bed-56a5-44c1-a7f2-dae633e65c87
+            granularity: 65536
+        [3]:
+            flags:
+                [0]: in-use
+                [1]: auto
+            name: 13056186-e65e-448e-a3c3-019ab25d3a27
+            granularity: 65536
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+```
+
+Also attaching the map where you can see there are plenty of zero blocks, but still it tries to allocate a new block for some reason.
+[map.txt](/uploads/0890cf718f77c0ad2e562165eb350d13/map.txt)