Re: [Qemu-devel] [Qemu-block] [PATCH] doc: Preallocation does not require writing zeroes

[Stefano Garzarella]

On Thu, Jul 11, 2019 at 03:29:35PM +0200, Max Reitz wrote:
> When preallocating an encrypted qcow2 image, it just lets the protocol
> driver write data and then does not mark the clusters as zero.
> Therefore, reading this image will yield effectively random data.
> 
> As such, we have not fulfilled the promise of always writing zeroes when
> preallocating an image in a while.  It seems that nobody has really
> cared, so change the documentation to conform to qemu's actual behavior.
> 
> Signed-off-by: Max Reitz <address@hidden>
> ---
>  qapi/block-core.json         | 9 +++++----
>  docs/qemu-block-drivers.texi | 4 ++--
>  qemu-img.texi                | 4 ++--
>  3 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 0d43d4f37c..a4363b84d2 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -5167,10 +5167,11 @@
>  # @off: no preallocation
>  # @metadata: preallocate only for metadata
>  # @falloc: like @full preallocation but allocate disk space by
> -#          posix_fallocate() rather than writing zeros.
> -# @full: preallocate all data by writing zeros to device to ensure disk
> -#        space is really available. @full preallocation also sets up
> -#        metadata correctly.
> +#          posix_fallocate() rather than writing data.
> +# @full: preallocate all data by writing it to the device to ensure
> +#        disk space is really available. This data may or may not be
> +#        zero, depending on the image format and storage.
> +#        @full preallocation also sets up metadata correctly.
>  #
>  # Since: 2.2
>  ##
> diff --git a/docs/qemu-block-drivers.texi b/docs/qemu-block-drivers.texi
> index 91ab0eceae..c02547e28c 100644
> --- a/docs/qemu-block-drivers.texi
> +++ b/docs/qemu-block-drivers.texi
> @@ -31,8 +31,8 @@ Supported options:
>  @item preallocation
>  Preallocation mode (allowed values: @code{off}, @code{falloc}, @code{full}).
>  @code{falloc} mode preallocates space for image by calling posix_fallocate().
> -@code{full} mode preallocates space for image by writing zeros to underlying
> -storage.
> +@code{full} mode preallocates space for image by writing data to underlying
> +storage.  This data may or may not be zero, depending on the storage 
> location.
>  @end table
>  
>  @item qcow2
> diff --git a/qemu-img.texi b/qemu-img.texi
> index c8e9bba515..b5156d6316 100644
> --- a/qemu-img.texi
> +++ b/qemu-img.texi
> @@ -666,8 +666,8 @@ Supported options:
>  @item preallocation
>  Preallocation mode (allowed values: @code{off}, @code{falloc}, @code{full}).
>  @code{falloc} mode preallocates space for image by calling posix_fallocate().
> -@code{full} mode preallocates space for image by writing zeros to underlying
> -storage.
> +@code{full} mode preallocates space for image by writing data to underlying
> +storage.  This data may or may not be zero, depending on the storage 
> location.
>  @end table
>  
>  @item qcow2

Just a question:
if a protocol driver returns 1 with the .bdrv_has_zero_init callback, is it
expected that the preallocation will fill the image with zeroes?

IIUC, for example, the qcow2 returns 1 with the .bdrv_has_zero_init. but during
the qcow2_co_truncate() it calls bdrv_co_truncate() and, depending on the
backend driver, it should fill the image with zeroes (or not?).

Maybe I miss something related to the metadata...


Thanks,
Stefano