diff options
Diffstat (limited to 'results/classifier/118/none/1523246')
| -rw-r--r-- | results/classifier/118/none/1523246 | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/results/classifier/118/none/1523246 b/results/classifier/118/none/1523246 new file mode 100644 index 000000000..4fc5abedf --- /dev/null +++ b/results/classifier/118/none/1523246 @@ -0,0 +1,125 @@ +virtual: 0.619 +user-level: 0.609 +register: 0.587 +device: 0.579 +graphic: 0.551 +permissions: 0.550 +peripherals: 0.548 +vnc: 0.529 +KVM: 0.526 +architecture: 0.525 +semantic: 0.519 +hypervisor: 0.517 +TCG: 0.509 +risc-v: 0.508 +ppc: 0.504 +network: 0.501 +debug: 0.497 +kernel: 0.492 +PID: 0.491 +performance: 0.477 +assembly: 0.471 +VMM: 0.468 +files: 0.458 +boot: 0.450 +arm: 0.423 +mistranslation: 0.402 +socket: 0.363 +x86: 0.329 +i386: 0.217 + +Virtio-blk does not support TRIM + +When model=virtio is used, TRIM is not supported. + +# mount -o discard /dev/vda4 /mnt +# mount | tail -1 +/dev/vda4 on /mnt type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096) +# fstrim /mnt/ +fstrim: /mnt/: the discard operation is not supported + +Booting without model=virtio allows using TRIM (in Windows as well). + +Full QEMU line: + +qemu-system-x86_64 -enable-kvm -cpu host -bios /usr/share/ovmf/ovmf_x64.bin -smp 2 -m 7G -vga qxl -usbdevice tablet -net nic,model=virtio -net user -drive discard=unmap,detect-zeroes=unmap,cache=none,file=vms/win10.hd.img.vmdk,format=vmdk,if=virtio + + + +Ideally there should be a warning if a user gives discard=unmap and isn't using the SCSI bus. Using the following options allows the guest to detect the drive as a thinly provisioned drive. + +-drive discard=unmap,detect-zeroes=unmap,cache=none,file=vms/win10.hd.img.vmdk,format=vmdk,if=none,id=hd -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd + + + +Virtio will never support discard requests. Please use virtio-scsi. + +So, please rename bug to "Feature request: Refuse to operate if virtio + discard is requested" + +> Virtio will never support discard requests. + + - what is that? + +> Please use virtio-scsi. + + - in some tests, SCSI emulation appears 7 times slower than the paravirtualized bus. + + +> Virtio will never support discard requests. + +Why? If you don't want to write a treatise on the subject, perhaps point at an LWN article or LKML thread where that conclusion was discussed or reached. + +> So, please rename bug to "Feature request: Refuse to operate if virtio + discard is requested" + +Uh, if the feature as requested will never be satisfied, WONTFIX it and create a feature that could be satisfied. Or WONTFIX it and take no further action. Either way, the status of things would be much clearer to use poor schmucks who land here googling the issue. + +discard support for virtio-blk is on the QEMU TODO list: + +http://wiki.qemu-project.org/ToDo/Block#virtio-blk_discard_support_.5BPeter_Lieven.5D + +Granted, it's been there since October of 2014. http://wiki.qemu-project.org/index.php?title=ToDo/Block&oldid=4410#virtio-blk_discard_support_.5BPeter_Lieven.5D + +I believe this feature was just merged by Linus about a week ago, and is in linux 5.0-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d548e65904ae43b0637d200a2441fc94e0589c30 + +While the Linux virtio-blk guest driver now supports discard and write zeroes, QEMU's virtio-blk device emulation does not support it yet. + +The DISCARD feature has now been implemented in QEMU, too: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=37b06f8d46fe602e630e4 + +On which version of qemu the discard option is supported? + +I have emulated a VM with below qemu options related to disk type: + +-drive file=disk.img,if=none,id=disk0,l2-cache-size=8M,format=qcow2,discard=on,detect-zeroes=unmap,aio=io_uring -device virtio-blk-pci,drive=disk0,scsi=off,bootindex=2 + +the disk file on the host side is located on xfs mountpoint on RAID level 10 array. + +After I downloaded a file with 1GB size on the guest OS, I saw the size of the disk file on the host has been increased as well. + +But when I delete the downloaded file and issue fstrim --all -v command, the disk file on host has not been decreased. + +The version of qemu I'm using is 5.2.0 + +$ git tag --contains 37b06f8d46fe602e630e4 | grep ^v | sort | head -n1 +v4.0.0 + +How did you check the size of the file? It might appear bigger than it is due to sparse blocks. + +I've checked the size of disk file with ls -alh and du --apparent-size commands + +I downloaded the 1G size file 5 times to make sure about sparse blocks issue, but the problem still exists + +I think you should check with "du" but without "--apparent-size" since that parameter counts the sparse blocks, too. See e.g.: + +$ truncate -s 10M test.dat +$ ls -alh test.dat +-rw-rw-r--. 1 root root 10M Dec 12 14:31 test.dat +$ du -sh --apparent-size test.dat +10M test.dat +$ du -sh test.dat +0 test.dat + + + +thanks. so now my question is that are these sparsed blocks rewritable? I mean after deletion of a file and downloading again, will these files be stored on the sparsed blocks or the number of starting block for write operation will be after the number of latest sparsed block? + |