qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Virtio-blk and trim


From: Brian Rak
Subject: Re: [Qemu-discuss] Virtio-blk and trim
Date: Wed, 01 Oct 2014 18:25:20 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0


On 10/1/2014 6:03 PM, Mike Lovell wrote:
On 09/30/2014 05:21 PM, 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.

i haven't been following the discussions on the qemu-devel mailing list in a while but i would be surprised if anyone is planning on adding discard to virtio-blk. part of the reason that virtio-scsi was created was that virtio-blk is hard to extend with new features.

if virtio-scsi is not an option for you, then maybe you could consider using ahci. there probably is going to be some amount of a performance hit but using ahci but maybe its small enough that its not a problem for you. there was not an easy way to use an virtual ahci disk controller using just the -drive option last time i checked. something like the following would do it.

-drive file=/path/to/virtual/disk.qcow,if=none,id=disk0 -device ahci,id=ahci0 -device ide-drive,id=ahci0-disk0,bus=ahci0.0,drive=disk0

this creates the virtual disk with an id of disk0, creates the virtual ahci controller with an id of ahci0, and then creates an connection of the virtual disk to the ahci controller on port 0 (the .0 part on the bus option). i know its also possible specify an virtual ahci controller when using libvirt but i don't know off the top of my head how to do that.

i am curious what kind of performance hits you have seen when switching from virtio-blk to virtio-scsi. i was under the impression there wasn't much if any performance difference.

mike


I saw about a 9% performance hit on reads (as measured by fbd: http://downloads.managedflash.com/Linux/fbd-102108a.tar.gz ), and a 20% performance hit on writes. Those are pretty significant numbers for us, we can't justify that much of a hit to disk performance in order to get the benefits of trim.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]