qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 05/12] block: add logical block provisioning inf


From: Peter Lieven
Subject: Re: [Qemu-devel] [PATCH 05/12] block: add logical block provisioning information to BlockDriverInfo
Date: Mon, 16 Sep 2013 13:30:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]