[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible
From: |
Kevin Wolf |
Subject: |
Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible |
Date: |
Thu, 21 Nov 2019 12:34:05 +0100 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
Am 21.11.2019 um 09:59 hat Max Reitz geschrieben:
> 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 <address@hidden>
> > ---
> > 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?
What else would be right? Returning an error?
Common cases (raw and qcow2 v3 without external data files) are quick
anyway.
> 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?
Do you really need a pause point? They call bdrv_co_truncate() from
inside the job coroutine, so it will yield. I would expect that this
is enough.
But in fact, all jobs have a pause point before even calling .run(), so
even if that made a difference, it should still be fine.
Kevin
signature.asc
Description: PGP signature
- [PATCH for-4.2? v2 0/6] block: Fix resize (extending) of short overlays, Kevin Wolf, 2019/11/20
- [PATCH v2 1/6] block: bdrv_co_do_pwrite_zeroes: 64 bit 'bytes' parameter, Kevin Wolf, 2019/11/20
- [PATCH v2 2/6] block: truncate: Don't make backing file data visible, Kevin Wolf, 2019/11/20
- Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible, Eric Blake, 2019/11/20
- Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible, Max Reitz, 2019/11/21
- Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible, Vladimir Sementsov-Ogievskiy, 2019/11/21
- Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible,
Kevin Wolf <=
- Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible, Max Reitz, 2019/11/21
- Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible, Kevin Wolf, 2019/11/21
- Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible, Max Reitz, 2019/11/21
- Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible, Alberto Garcia, 2019/11/22
Re: [PATCH v2 2/6] block: truncate: Don't make backing file data visible, Alberto Garcia, 2019/11/22
[PATCH v2 4/6] iotests: Fix timeout in run_job(), Kevin Wolf, 2019/11/20
[PATCH v2 3/6] iotests: Add qemu_io_log(), Kevin Wolf, 2019/11/20
[PATCH v2 5/6] iotests: Support job-complete in run_job(), Kevin Wolf, 2019/11/20