1 files changed, 76 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/files/1920211 b/results/classifier/zero-shot/118/files/1920211
new file mode 100644
index 000000000..3e235058d
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1920211
@@ -0,0 +1,76 @@
+files: 0.887
+performance: 0.878
+device: 0.815
+hypervisor: 0.739
+user-level: 0.731
+semantic: 0.728
+kernel: 0.714
+architecture: 0.712
+network: 0.702
+graphic: 0.683
+PID: 0.663
+permissions: 0.634
+register: 0.618
+i386: 0.608
+mistranslation: 0.598
+risc-v: 0.589
+x86: 0.586
+socket: 0.585
+arm: 0.582
+ppc: 0.556
+peripherals: 0.547
+vnc: 0.539
+debug: 0.515
+TCG: 0.502
+VMM: 0.499
+virtual: 0.495
+KVM: 0.483
+boot: 0.447
+assembly: 0.441
+
+shrink option for discard (for bad host-filesystems and -backup solutions)
+
+When using discard=unmap for virtio or scsi devices with QCOW2 images, space discarded by the guest will be unmaped on the host, which is basically great!
+
+This will turn the QCOW2 image into a sparse file which is efficient for most scenarios. But it may be that you need to avoid big sparse files on your host. For example because you need to use a backup solution which doesn't support sparse files well. Or maybe the QCOW2 image is on a filesystem mount which doesn't support sparse files at all.
+
+For those scenarios an alternative option for the discard setting (discard=shrink) would be great, so that the QCOW2 file itself gets shrunken again.
+I'm not sure about how the initial growing* of QCOW2 images is implemented and if there are maybe limitations. But I hope it may be possible do the inverse and actually shrink (not sparse) an QCOW2 image with internally discarded blocks.
+
+
+I'm using Qemu-5.2.0 and Linux >= 5.3 (host and guest).
+
+*If you use "qemu-img create -f qcow2 ..." withOUT the "preallocation" option.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+