qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: John Snow <jsnow@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: kwolf@redhat.com, armbru@redhat.com, mreitz@redhat.com, den@openvz.org
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v3 1/3] block: add bdrv_get_format_alloc_stat format interface
Date: Thu, 29 Jun 2017 20:14:46 -0500	[thread overview]
Message-ID: <ea5ac81f-14f5-62fb-d91d-60e729939d3a@redhat.com> (raw)
In-Reply-To: <6e4fe097-c125-9f0b-1716-e12173f73e67@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2017-06-30  1:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-06 16:26 [Qemu-devel] [PATCH v3 0/3] qemu-img check: format allocation info Vladimir Sementsov-Ogievskiy
2017-06-06 16:26 ` [Qemu-devel] [PATCH v3 1/3] block: add bdrv_get_format_alloc_stat format interface Vladimir Sementsov-Ogievskiy
2017-06-26 23:19   ` [Qemu-devel] [Qemu-block] " John Snow
2017-06-28 15:59     ` Vladimir Sementsov-Ogievskiy
2017-06-29  0:15       ` John Snow
2017-06-29  6:59         ` Vladimir Sementsov-Ogievskiy
2017-06-29 21:44           ` John Snow
2017-06-30  0:27   ` John Snow
2017-06-30  0:45     ` Eric Blake
2017-06-30  0:54       ` John Snow
2017-06-30  1:14         ` Eric Blake [this message]
2017-07-12 15:18     ` Vladimir Sementsov-Ogievskiy
2017-07-24 12:45       ` Vladimir Sementsov-Ogievskiy
2017-07-27 21:23       ` John Snow
2017-07-28  8:25         ` Vladimir Sementsov-Ogievskiy
2017-07-28 12:05         ` Eric Blake
2017-06-06 16:26 ` [Qemu-devel] [PATCH v3 2/3] qcow2: add .bdrv_get_format_alloc_stat Vladimir Sementsov-Ogievskiy
2017-06-06 16:26 ` [Qemu-devel] [PATCH v3 3/3] qemu-img check: add format allocation info Vladimir Sementsov-Ogievskiy
2017-06-21 11:08 ` [Qemu-devel] ping Re: [PATCH v3 0/3] qemu-img check: " Vladimir Sementsov-Ogievskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea5ac81f-14f5-62fb-d91d-60e729939d3a@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).