When extending the size of an image that has a backing file larger than
its old size, make sure that the backing file data doesn't become
visible in the guest, but the added area is properly zeroed out.
Consider the following scenario where the overlay is shorter than its
backing file:
base.qcow2: AAAAAAAA
overlay.qcow2: BBBB
When resizing (extending) overlay.qcow2, the new blocks should not stay
unallocated and make the additional As from base.qcow2 visible like
before this patch, but zeros should be read.
A similar case happens with the various variants of a commit job when an
intermediate file is short (- for unallocated):
base.qcow2: A-A-AAAA
mid.qcow2: BB-B
top.qcow2: C--C--C-
After commit top.qcow2 to mid.qcow2, the following happens:
mid.qcow2: CB-C00C0 (correct result)
mid.qcow2: CB-C--C- (before this fix)
Without the fix, blocks that previously read as zeros on top.qcow2
suddenly turn into A.
Signed-off-by: Kevin Wolf <address@hidden>
---
block/io.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
+ if (new_bytes && bs->backing && prealloc == PREALLOC_MODE_OFF) {
+ int64_t backing_len;
+
+ backing_len = bdrv_getlength(backing_bs(bs));
+ if (backing_len < 0) {
+ ret = backing_len;
+ goto out;
+ }
+
+ if (backing_len > old_size) {
+ ret = bdrv_co_do_pwrite_zeroes(
+ bs, old_size, MIN(new_bytes, backing_len - old_size),
+ BDRV_REQ_ZERO_WRITE | BDRV_REQ_MAY_UNMAP);
+ if (ret < 0) {
+ goto out;
+ }
+ }
+ }