From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Lieven <pl@kamp.de>
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: Mon, 16 Sep 2013 13:37:50 +0200 [thread overview]
Message-ID: <5236ED8E.1080008@redhat.com> (raw)
In-Reply-To: <5236EBD1.3000506@kamp.de>
Il 16/09/2013 13:30, Peter Lieven ha scritto:
> On 13.09.2013 13:45, Paolo Bonzini wrote:
>> 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.
>>
>> 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.
>
> Would you also be ok to introduce bdrv_has_discard_zeroes()
> and bdrv_has_discard_write_zeroes() as Kevin suggested to avoid the need to
> add the logic to return 0 if there is a bs->backing_hd everywhere.
If Kevin says it, I agree. :)
> This would also make the use of it easier as it avoids the steps
> necessary to invoke bdrv_get_info().
Another possibility could be to put the "info" in a member of
BlockDriverState, since it is static. Then bdrv_get_info() could be simply
return &bs->info;
which is faster and removes the need for a BlockDriverInfo temporary.
Paolo
next prev parent reply other threads:[~2013-09-16 11:38 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
2013-09-13 12:58 ` Paolo Bonzini
2013-09-16 11:30 ` Peter Lieven
2013-09-16 11:37 ` Paolo Bonzini [this message]
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=5236ED8E.1080008@redhat.com \
--to=pbonzini@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=kwolf@redhat.com \
--cc=pl@kamp.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.