diff options
author | Max Reitz <mreitz@redhat.com> | 2019-07-24 19:12:31 +0200 |
---|---|---|
committer | Max Reitz <mreitz@redhat.com> | 2019-08-19 17:13:26 +0200 |
commit | ceaca56feee6a1d682c882300855cad44a67ec8e (patch) | |
tree | 28fe6b35daa9996adbc486fe57b7c606ff602fdc /block/gluster.c | |
parent | cdf3bc934ad1e5319b03f2c85f381f5ffd2f8ca8 (diff) | |
download | qemu-ceaca56feee6a1d682c882300855cad44a67ec8e.zip qemu-ceaca56feee6a1d682c882300855cad44a67ec8e.tar.gz qemu-ceaca56feee6a1d682c882300855cad44a67ec8e.tar.bz2 |
block: Add bdrv_has_zero_init_truncate()
No .bdrv_has_zero_init() implementation returns 1 if growing the file
would add non-zero areas (at least with PREALLOC_MODE_OFF), so using it
in lieu of this new function was always safe.
But on the other hand, it is possible that growing an image that is not
zero-initialized would still add a zero-initialized area, like when
using nonpreallocating truncation on a preallocated image. For callers
that care only about truncation, not about creation with potential
preallocation, this new function is useful.
Alternatively, we could have added a PreallocMode parameter to
bdrv_has_zero_init(). But the only user would have been qemu-img
convert, which does not have a plain PreallocMode value right now -- it
would have to parse the creation option to obtain it. Therefore, the
simpler solution is to let bdrv_has_zero_init() inquire the
preallocation status and add the new bdrv_has_zero_init_truncate() that
presupposes PREALLOC_MODE_OFF.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20190724171239.8764-4-mreitz@redhat.com
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Diffstat (limited to 'block/gluster.c')
0 files changed, 0 insertions, 0 deletions