On 06/29/2017 07:54 PM, John Snow wrote:
>> Not necessarily an error, if it corresponds to a section that the guest >> has done a TRIM operation on, but where we did not have the means to >> punch a hole in the protocol layer. The semantics of guest TRIM is that >> the data can no longer be reliably read, making it weaker (and thus >> easier to implement) than explicitly writing things to zero (although >> writing zeroes can often be sped up by trimming, when you have >> guarantees on what will be read later). >> > > But the data is considered "used" -- if it cannot be reliably read but > the format driver expects to be able to read it, is this not inherently > a category that signifies a semantic error? It's a semantic error if the region belongs to the metadata portion of the format driver, but not necessarily a problem if it belongs to the guest-visible contents. You're right that a guest probably shouldn't read from areas that it trimmed, but since it is possible to do that on bare metal block devices, it is reasonable that a format driver can emulate what happens when a guest reads from trimmed (but unknown-content) clusters. You're also right that qcow2 probably can't get into this situation (qcow2 v3 files always turned guest-trimmed clusters into read-as-zero; and qcow2 v2 files discard the cluster treating it as unused rather than used, thereby deferring to the backing image). It also corresponds somewhat to the behavior you get when putting a qcow2 format on top of a block device (creating qcow2 as a POSIX file gives you some nice assurances from the filesystem that clusters you haven't touched read as zero; but not so with a brand-new qcow2 file on a block device, where reads can be random until the first write) > Data that is considered "Discarded" by the protocol (we succeeded in > passing on the TRIM request from the guest through to the protocol) > should almost certainly no longer be considered "used" by the format...? The qcow2 format doesn't have a way to specifically represent a cluster as discarded in this manner, but other protocols might. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
