d hee
2013-Mar-17 11:15 UTC
[libvirt-users] SSD Trim needed? Physical Block Device Keep Track Of Guest FS Blocks?
I am trying to figure out if a SSD drive needs to receive trim commands from the KVM guest filesystem(strictly Linux ext4 in this case).... When a file is deleted inside a KVM guest(ext4 and raw image)....If a SSD is the underlying block device that the KVM raw disk image resides on, does the SDD drive need to know which block(s) are marked for reuse within the raw image? ?Or is it since the Guest raw image is a container that the physical hard drive has no concern about the filesystem blocks within the Guest? Meaning the physical disk would only be concerned with the image itself as a whole...such as if the whole image was deleted? Thanks, -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20130317/04469cd8/attachment.htm>
Eric Blake
2013-Mar-20 23:26 UTC
[libvirt-users] SSD Trim needed? Physical Block Device Keep Track Of Guest FS Blocks?
On 03/17/2013 05:15 AM, d hee wrote:> I am trying to figure out if a SSD drive needs to receive trim commands from the KVM guest filesystem(strictly Linux ext4 in this case).... > > When a file is deleted inside a KVM guest(ext4 and raw image)....If a SSD is the underlying block device that the KVM raw disk image resides on, does the SDD drive need to know which block(s) are marked for reuse within the raw image? Or is it since the Guest raw image is a container that the physical hard drive has no concern about the filesystem blocks within the Guest? Meaning the physical disk would only be concerned with the image itself as a whole...such as if the whole image was deleted?[Any way you can convince your mailer to wrap long lines?] Upstream qemu is hoping to add new options to control how far a TRIM command in a guest is propagated back to the host storage, whether raw file or block device in the host. Paolo Bonzini is spear-heading that effort. But until qemu 1.5 is released with more options for controlling what happens, we don't yet have the libvirt design in place to expose those options. https://lists.gnu.org/archive/html/qemu-devel/2013-02/msg01252.html -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 621 bytes Desc: OpenPGP digital signature URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20130320/5a11e918/attachment.sig>