From: Peter Lieven <pl@kamp.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kwolf@redhat.com, ronniesahlberg@gmail.com, stefanha@redhat.com,
qemu-devel@nongnu.org, anthony@codemonkey.ws
Subject: Re: [Qemu-devel] [PATCH 05/12] block: add logical block provisioning information to BlockDriverInfo
Date: Fri, 13 Sep 2013 14:22:30 +0200 [thread overview]
Message-ID: <52330386.8010709@kamp.de> (raw)
In-Reply-To: <5232FAC7.7030001@redhat.com>
Am 13.09.2013 13:45, schrieb Paolo Bonzini:
> Il 13/09/2013 12:44, Peter Lieven ha scritto:
>> On 13.09.2013 12:34, Paolo Bonzini wrote:
>>> Il 13/09/2013 12:25, Peter Lieven ha scritto:
>>>> + /* maximum number of sectors that can be discarded at once */
>>>> + int max_discard;
>>>> + /* maximum number of sectors that can zeroized at once */
>>>> + int max_write_zeroes;
>>> These should not be needed outside the driver.
>>>
>>> If you want to make them private between block.c and block/iscsi.c, you
>>> can add them to BlockDriverState.
>> The question is, if the discard_zeroes or discard_write_zeroes is needed
>> outside the driver as well?
>>
>> I can put the max_* information in the block driver state. I also thought
>> to add alignment and granularity information even if they are currently
>> not yet used.
> Yeah, in fact bdrv_write_zeroes and bdrv_discard can be taught to split
> requests according to these parameters instead of introducing a new
> function bdrv_zeroize. You don't need bdrv_zeroize I think; you can
> simply use bdrv_write_zeroes. This is why I don't like this information
> in BlockDriverInfo.
bdrv_zeroize has one big advantage over a bdrv_write_zeroes over
the whole device: it checks the block status before it sends requests.
this can be a great performance benefit if a lot of blocks are already
unmapped. so i would like to keep it in, but simplifiy it (see below).
>
> On the contrary, discard_write_zeroes is useful to "generic" clients,
> and your qemu-img patch shows why.
>
> Discard_zeroes is somewhere in the middle. You only use it in
> bdrv_get_block_status, but it is not something that should be hidden to
> users of the high-level block.c API. So it is fine to leave it in
> BlockDriverInfo.
okay, i will leave them in and put
max_discard
discard_alignment
max_write_zeroes
write_zeroes_alignment
into the BlockDriverState. I would then like to call out to all
driver developers to set these values for their drivers
to good values.
For now I can factor out the request split logic out of
iscsi_co_discard, iscsi_co_write_zeroes and bdrv_sanitize
and put them in bdrv_co_discard and bdrv_co_write_zeroes.
I would like to leave the misalignment logic to a later patch.
What would you think are reasonable default values for
max_discard and max_write_zeroes?
Peter
next prev parent reply other threads:[~2013-09-13 12:23 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 10:24 [Qemu-devel] [PATCH 00/12] block: logical block provisioning enhancements Peter Lieven
2013-09-13 10:24 ` [Qemu-devel] [PATCH 01/12] block: make BdrvRequestFlags public Peter Lieven
2013-09-13 16:29 ` Eric Blake
2013-09-13 10:24 ` [Qemu-devel] [PATCH 02/12] block: add flags to bdrv_*_write_zeroes Peter Lieven
2013-09-13 16:58 ` Eric Blake
2013-09-13 10:25 ` [Qemu-devel] [PATCH 03/12] block: introduce BDRV_REQ_MAY_UNMAP in bdrv_co_write_zeroes Peter Lieven
2013-09-13 18:07 ` Eric Blake
2013-09-13 10:25 ` [Qemu-devel] [PATCH 04/12] iscsi: add .bdrv_co_write_zeroes Peter Lieven
2013-09-13 18:10 ` Eric Blake
2013-09-13 10:25 ` [Qemu-devel] [PATCH 05/12] block: add logical block provisioning information to BlockDriverInfo Peter Lieven
2013-09-13 10:34 ` Paolo Bonzini
2013-09-13 10:44 ` Peter Lieven
2013-09-13 11:45 ` Paolo Bonzini
2013-09-13 12:22 ` Peter Lieven [this message]
2013-09-13 12:58 ` Paolo Bonzini
2013-09-16 11:30 ` Peter Lieven
2013-09-16 11:37 ` Paolo Bonzini
2013-09-13 10:25 ` [Qemu-devel] [PATCH 06/12] iscsi: add .bdrv_get_info Peter Lieven
2013-09-13 18:19 ` Eric Blake
2013-09-13 10:25 ` [Qemu-devel] [PATCH 07/12] block: introduce bdrv_zeroize Peter Lieven
2013-09-13 10:47 ` Peter Lieven
2013-09-13 18:23 ` Eric Blake
2013-09-13 10:25 ` [Qemu-devel] [PATCH 08/12] qemu-img: conditionally zero out target on convert Peter Lieven
2013-09-13 10:36 ` Paolo Bonzini
2013-09-13 10:46 ` Peter Lieven
2013-09-13 11:35 ` Paolo Bonzini
2013-09-13 18:25 ` Eric Blake
2013-09-13 19:48 ` Peter Lieven
2013-09-13 19:52 ` Eric Blake
2013-09-16 11:01 ` Paolo Bonzini
2013-09-13 10:25 ` [Qemu-devel] [PATCH 09/12] block/get_block_status: set *pnum = 0 on error Peter Lieven
2013-09-13 18:26 ` Eric Blake
2013-09-13 10:25 ` [Qemu-devel] [PATCH 10/12] block/get_block_status: avoid segfault if there is no backing_hd Peter Lieven
2013-09-13 18:26 ` Eric Blake
2013-09-13 10:25 ` [Qemu-devel] [PATCH 11/12] block/get_block_status: avoid redundant callouts on raw devices Peter Lieven
2013-09-13 18:28 ` Eric Blake
2013-09-13 10:25 ` [Qemu-devel] [PATCH 12/12] block/get_block_status: fix BDRV_BLOCK_ZERO for unallocated blocks Peter Lieven
2013-09-13 13:53 ` Eric Blake
2013-09-16 5:47 ` Peter Lieven
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=52330386.8010709@kamp.de \
--to=pl@kamp.de \
--cc=anthony@codemonkey.ws \
--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).