diff options
Diffstat (limited to 'results/classifier/zero-shot/118/files/1920211')
| -rw-r--r-- | results/classifier/zero-shot/118/files/1920211 | 76 |
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 00000000..3e235058 --- /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.] + |