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 <mre...@redhat.com>
> ---
> 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
