block: truncate: Don't make backing file data visible
commit955c7d6687fefcd903900a1e597fcbc896c661cd
authorKevin Wolf <kwolf@redhat.com>
Fri, 24 Apr 2020 12:54:45 +0000 (24 14:54 +0200)
committerKevin Wolf <kwolf@redhat.com>
Thu, 30 Apr 2020 15:51:07 +0000 (30 17:51 +0200)
tree46b3c6083f608237bfaa670b5fb60cd95c0adb5d
parent2f0c6e7a650de133eccd94e9bb6cf7b2070f07f1
block: truncate: Don't make backing file data visible

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 <kwolf@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200424125448.63318-8-kwolf@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block/io.c