From: Peter Lieven <pl@kamp.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
ronnie sahlberg <ronniesahlberg@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert
Date: Thu, 18 Jul 2013 13:04:40 +0200 [thread overview]
Message-ID: <51E7CBC8.1010804@kamp.de> (raw)
In-Reply-To: <51E7C9C4.5010202@redhat.com>
On 18.07.2013 12:56, Paolo Bonzini wrote:
> Il 18/07/2013 12:44, Peter Lieven ha scritto:
>> On 18.07.2013 12:24, Paolo Bonzini wrote:
>>> Il 18/07/2013 11:23, Kevin Wolf ha scritto:
>>>> Am 17.07.2013 um 19:48 hat Peter Lieven geschrieben:
>>>>> Am 17.07.2013 um 19:04 schrieb Paolo Bonzini <pbonzini@redhat.com>:
>>>>>
>>>>>> Il 17/07/2013 19:02, Peter Lieven ha scritto:
>>>>>>> For Disks we always use read/write16 so i think we Should also use
>>>>>>> writesame16. Or not?
>>>>>> Yes.
>>>>>>
>>>>>> Remember you can still use UNMAP if LBPRZ=0.
>>>>> I can always use it if writesame is not available, but in this case
>>>>> bdi->discard_zeroes must be 0.
>>>>>
>>>>> Maybe we should call it discard_writes_zeroes or similar.
>>>>>
>>>>> Discard_zeroes is sth that should only indicate if lbprz == 1. At
>>>>> least if we refer to the Linux ioctl. We could include both in BDI.
>>>> Maybe what we really should do is to define different operations (with
>>>> an exact behaviour) instead of having one bdrv_discard() and then adding
>>>> flags everywhere to tell what the operation is doing exactly.
>>> A BDRV_MAY_UNMAP flag for bdrv_write_zeroes?
>> I thought that we wanted to add a paramter to the BDI (call it
>> write_zeroes_w_discard).
> I also thought so, but I like Kevin's idea of not shoehorning it in
> bdrv_discard(). Extending bdrv_write_zeroes is a better API.
>
> So far we've avoided "discard zeroes" semantics in QEMU (device models
> are also careful not to expose that). Since the only sane way to
> implement what you want is to use the SCSI WRITE SAME command, adding
> flags to bdrv_write_zeroes will even be easier because the mapping with
> SCSI is natural: discard = UNMAP, write_zeroes = WRITE SAME (either
> without or with the UNMAP bit).
>
>> If this is set the bdrv MUST accept a flag to bdrv_discard() lets call
>> it BDRV_DISCARD_WRITE_ZEROES
>> and he has to ensure that all sectors specified in bdrv_discard() read
>> as zero after the operation.
>>
>> If this flag is not set (e.g. when the OS issues a normal discard) the
>> operation may still silently fail with
>> undefined provisioning state and content of the specified sectors.
> But if you set BDRV_DISCARD_WRITE_ZEROES, then you always need a
> fallback to bdrv_write_zeroes. Why not just call bdrv_write_zeroes to
> begin with? That's why extending bdrv_write_zeroes is preferable.
In this case wo do not need a flag to the function at all. If the
driver sets bdi->write_zeroes_w_discard = 1 then bdrv_write_zeroes
can use bdrv_discard to write zeroes and the driver has to
ensure that all is zero afterwards.
If the driver would have a better method of writing zeroes than
discard it simply should not set bdi->write_zeroes_w_discard = 1.
Peter
next prev parent reply other threads:[~2013-07-18 11:04 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-15 10:49 [Qemu-devel] [PATCH 0/4] qemu-img: conditionally discard target on convert Peter Lieven
2013-07-15 10:49 ` [Qemu-devel] [PATCH 1/4] block: add discard_zeroes and max_unmap to BlockDriverInfo Peter Lieven
2013-07-15 10:49 ` [Qemu-devel] [PATCH 2/4] iscsi: add .bdrv_get_info Peter Lieven
2013-07-15 10:49 ` [Qemu-devel] [PATCH 3/4] block/raw: " Peter Lieven
2013-07-19 5:12 ` Stefan Hajnoczi
2013-07-15 10:49 ` [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert Peter Lieven
2013-07-17 8:46 ` Kevin Wolf
2013-07-17 9:58 ` Paolo Bonzini
2013-07-17 10:21 ` Peter Lieven
2013-07-17 10:27 ` Kevin Wolf
2013-07-17 10:31 ` Peter Lieven
2013-07-17 10:47 ` Paolo Bonzini
2013-07-17 14:19 ` Peter Lieven
2013-07-17 10:45 ` Paolo Bonzini
2013-07-17 14:21 ` Peter Lieven
2013-07-17 14:26 ` Paolo Bonzini
2013-07-17 10:25 ` Kevin Wolf
2013-07-17 15:54 ` ronnie sahlberg
2013-07-17 16:27 ` Paolo Bonzini
2013-07-17 16:31 ` ronnie sahlberg
2013-07-17 17:02 ` Peter Lieven
2013-07-17 17:04 ` Paolo Bonzini
2013-07-17 17:48 ` Peter Lieven
2013-07-17 20:00 ` Paolo Bonzini
2013-07-18 9:23 ` Kevin Wolf
2013-07-18 10:24 ` Paolo Bonzini
2013-07-18 10:42 ` Kevin Wolf
2013-07-18 10:44 ` Peter Lieven
2013-07-18 10:56 ` Paolo Bonzini
2013-07-18 11:04 ` Peter Lieven [this message]
2013-07-18 12:31 ` Paolo Bonzini
2013-07-18 13:29 ` Peter Lieven
2013-07-18 13:52 ` Paolo Bonzini
2013-07-18 14:09 ` Peter Lieven
2013-07-18 14:20 ` Paolo Bonzini
2013-07-18 14:32 ` Peter Lieven
2013-07-18 14:35 ` Paolo Bonzini
2013-07-18 18:43 ` Peter Lieven
2013-07-18 18:54 ` ronnie sahlberg
2013-07-18 19:28 ` Peter Lieven
2013-07-19 5:58 ` Paolo Bonzini
2013-07-19 6:08 ` Peter Lieven
2013-07-19 13:25 ` ronnie sahlberg
2013-07-19 13:49 ` Peter Lieven
2013-07-19 14:00 ` ronnie sahlberg
2013-07-19 14:02 ` Peter Lieven
2013-07-19 13:58 ` ronnie sahlberg
2013-07-18 13:55 ` ronnie sahlberg
2013-07-18 14:14 ` Paolo Bonzini
2013-09-12 8:52 ` Peter Lieven
2013-09-12 8:55 ` Paolo Bonzini
2013-09-12 9:03 ` Peter Lieven
2013-07-17 17:09 ` ronnie sahlberg
2013-07-18 9:21 ` Kevin Wolf
2013-07-17 10:22 ` Peter Lieven
2013-07-16 10:55 ` [Qemu-devel] [PATCH 0/4] " Paolo Bonzini
2013-07-16 11:18 ` Peter Lieven
2013-07-16 11:27 ` Paolo Bonzini
2013-07-16 11:40 ` Peter Lieven
2013-07-16 11:55 ` Paolo Bonzini
2013-07-17 10:23 ` Peter Lieven
2013-07-17 10:28 ` Paolo Bonzini
2013-07-17 10:40 ` Peter Lieven
2013-07-17 10:50 ` Paolo Bonzini
2013-07-17 14:18 ` Peter Lieven
2013-07-17 14:26 ` Paolo Bonzini
2013-07-17 14:46 ` Peter Lieven
2013-07-17 14:53 ` Paolo Bonzini
2013-07-17 15:12 ` Kevin Wolf
2013-07-17 16:53 ` Peter Lieven
2013-07-17 17:01 ` Peter Lieven
2013-07-19 5:13 ` Stefan Hajnoczi
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=51E7CBC8.1010804@kamp.de \
--to=pl@kamp.de \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=ronniesahlberg@gmail.com \
--cc=stefanha@redhat.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).