qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Denis V. Lunev" <den@openvz.org>
To: Kevin Wolf <kwolf@redhat.com>
Cc: "qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Max Reitz <mreitz@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Fam Zheng <fam@euphon.net>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"dgilbert@redhat.com" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/1] block: propagate discard aligment from format drivers to the guest
Date: Wed, 27 Feb 2019 12:32:00 +0000	[thread overview]
Message-ID: <d200c71d-c739-fd52-dcff-00d442b289ae@openvz.org> (raw)
In-Reply-To: <20190226155131.GC4598@linux.fritz.box>

On 2/26/19 6:51 PM, Kevin Wolf wrote:
> Am 26.02.2019 um 15:59 hat Denis V. Lunev geschrieben:
>> Nowaday SCSI drivers in guests are able to alight UNMAP requests before
> Is s/alight/align/ what you mean?
>
> The subject line has an "alignment" typo, too.
>
>> sending to the device. Right now QEMU provides an ability to set
>> this via "discard_granularity" property of the block device which could
>> be used by management layer.
>>
>> Though, in particular, from the point of QEMU, there is
>> pdiscard_granularity on the format driver level, f.e. on QCOW2 or iSCSI.
>> It would be beneficial to pass this value as a default for this
>> property.
>>
>> Technically this should reduce the amount of useless UNMAP requests
>> from the guest to the host.
>>
>> Signed-off-by: Denis V. Lunev <den@openvz.org>
>> CC: Kevin Wolf <kwolf@redhat.com>
>> CC: Max Reitz <mreitz@redhat.com>
>> CC: Paolo Bonzini <pbonzini@redhat.com>
>> CC: Fam Zheng <fam@euphon.net>
> I'm not doing things like this very often, but you're touching the guest
> ABI here, which is a bit tricky. The main point is that the same command
> line must result in the same guest view.
>
> You'll need at least some machine type magic to make old machine types
> use the old defaults. I'm not sure if there's something else to consider
> for migration compatibility.
>
> Kevin
sounds reasonable, thank you for the suggestion.

I was fascinated with the fact that
a) change is not  disruptive
b) the guest actually do not read this value except on controller reset and
    it is safe to return different value on a new request. This is not a
very
    big deal.

Den

      reply	other threads:[~2019-02-27 13:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26 14:59 [Qemu-devel] [PATCH 1/1] block: propagate discard aligment from format drivers to the guest Denis V. Lunev
2019-02-26 15:51 ` Kevin Wolf
2019-02-27 12:32   ` Denis V. Lunev [this message]

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=d200c71d-c739-fd52-dcff-00d442b289ae@openvz.org \
    --to=den@openvz.org \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).