21.11.2019 11:59, Max Reitz wrote: > On 20.11.19 19:44, Kevin Wolf wrote: >> 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 <kw...@redhat.com> >> --- >> block/io.c | 32 ++++++++++++++++++++++++++++++++ >> 1 file changed, 32 insertions(+) > > Zeroing the intersection may take some time. So is it right for QMP’s > block_resize to do this, seeing it is a synchronous operation? > > As far as I can tell, jobs actually have the same problem. I don’t > think mirror or commit have a pause point before truncating, so they > still block the monitor there, don’t they? > > Max >
For mirror there is alternative way: we may somehow cheat with block-status to consider space after EOF as allocated on upper level, then mirror will ZERO it by itself.. -- Best regards, Vladimir
