Virtio-blk does not support TRIM

[David Manouchehri]

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

[David Manouchehri (manouchehri)]

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

[Коренберг Марк (socketpair)]

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"

[Rustam Abdullaev (rustamabd)]

> 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.

[Mike Mol (mikemol)]

> 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.

[Mike Mol (mikemol)]

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

[Mike Mol (mikemol)]

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

[James Harvey (jamespharvey20)]

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

[Stefan Hajnoczi (stefanha)]

While the Linux virtio-blk guest driver now supports discard and write zeroes, QEMU's virtio-blk device emulation does not support it yet.

[Thomas Huth (th-huth)]

The DISCARD feature has now been implemented in QEMU, too:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=37b06f8d46fe602e630e4

[mohammadreza nasrabadi (mareza)]

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

[Thomas Huth (th-huth)]

$ 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.

[mohammadreza nasrabadi (mareza)]

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

[Thomas Huth (th-huth)]

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

[mohammadreza nasrabadi (mareza)]

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?