Patchwork [05/12] block: add logical block provisioning information to BlockDriverInfo

login
register
mail settings
Submitter Peter Lieven
Date Sept. 13, 2013, 10:25 a.m.
Message ID <1379067909-22984-6-git-send-email-pl@kamp.de>
Download mbox | patch
Permalink /patch/274714/
State New
Headers show

Comments

Peter Lieven - Sept. 13, 2013, 10:25 a.m.
Signed-off-by: Peter Lieven <pl@kamp.de>
---
 include/block/block.h |    9 +++++++++
 1 file changed, 9 insertions(+)
Paolo Bonzini - Sept. 13, 2013, 10:34 a.m.
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.

Paolo
Peter Lieven - Sept. 13, 2013, 10:44 a.m.
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.

Peter
Paolo Bonzini - Sept. 13, 2013, 11:45 a.m.
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.

Paolo
Peter Lieven - Sept. 13, 2013, 12:22 p.m.
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
Paolo Bonzini - Sept. 13, 2013, 12:58 p.m.
Il 13/09/2013 14:22, Peter Lieven ha scritto:
> 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).

Good idea.

> 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.

Sure.

> What would you think are reasonable default values for
> max_discard and max_write_zeroes?

32768 (16 MB) is the highest power-of-two amount that fits in 16 bits
assuming 512-byte sectors.  But you could also take a look at what the
Linux kernel does in drivers/scsi/sd.c.

Paolo
Peter Lieven - Sept. 16, 2013, 11:30 a.m.
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.

This would also make the use of it easier as it avoids the steps
necessary to invoke bdrv_get_info().

Peter
Paolo Bonzini - Sept. 16, 2013, 11:37 a.m.
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

Patch

diff --git a/include/block/block.h b/include/block/block.h
index 599de7d..ee17048 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -18,6 +18,15 @@  typedef struct BlockDriverInfo {
     /* offset at which the VM state can be saved (0 if not possible) */
     int64_t vm_state_offset;
     bool is_dirty;
+    /* do discarded blocks read back as zeroes? */
+    bool discard_zeroes;
+    /* is write zeroes optimized by a discard/unmap operation?
+     * this requires support for the BDRV_REQ_MAY_UNMAP flag. */
+    bool discard_write_zeroes;
+    /* 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;
 } BlockDriverInfo;
 
 typedef struct BlockFragInfo {