It makes a huge amount of sense for any backend that has sparse
storage, including:
- qcow2 (and all other cow formats).
- raw files on any host file system that supports sparse files.
- anything which caches the (virtual) sectors host side.
- anything which supports discard/trim/puncture/whateveryoucallit
at a lower level
This pretty much covers all the qemu storage backends.
And what makes it so hard to add commands to virtio-blk, given that
any host not issuingdiscard commands will continue to function
normally, and presuming there is a way todetect the qemu version
from inside the host and/or a way to issue commands that the host
qemu might ignore if unimplemented.
On 01/10/2014 22:24, Tony Su wrote:
I don't know that it makes any sense to run a TRIM/discard function
in a virtual file system.
It only makes sense for the command to be applied directly to the disk
at the hardware I/O level.
So, if you run the command on your HostOS regularly, it should addres
the needs for all GuestOS as well as the HostOS.
Tony
On Wed, Oct 1, 2014 at 1:19 PM, George Shuklin
<address@hidden> wrote:
It's better to name it 'discard', because TRIM a very specific ATA
command.
It done completely different in SCSI and slightly different in SD
cards. But
linux call it 'discard', or, to be precise, BLKDISCARD (name of ioctl).
On 10/01/2014 02:21 AM, Brian Rak wrote:
Are there any plans to bring trim support to Virtio-blk? We've got a
couple things that would be made nicer by having working trim support.
I see that it's implemented in virtio-scsi, but there's a decent
performance hit for switching over to that.
Enjoy
Jakob