[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/3] vpc: Do not return RAW from block_status
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 3/3] vpc: Do not return RAW from block_status |
Date: |
Tue, 13 Aug 2019 12:38:38 +0200 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
Am 12.08.2019 um 17:56 hat Max Reitz geschrieben:
> On 12.08.19 17:33, Vladimir Sementsov-Ogievskiy wrote:
> > 25.07.2019 18:55, Max Reitz wrote:
> >> vpc is not really a passthrough driver, even when using the fixed
> >> subformat (where host and guest offsets are equal). It should handle
> >> preallocation like all other drivers do, namely by returning
> >> DATA | RECURSE instead of RAW.
> >>
> >> There is no tangible difference but the fact that bdrv_is_allocated() no
> >> longer falls through to the protocol layer.
> >
> > Hmm. Isn't a real bug (fixed by this patch) ?
> >
> > Assume vpc->file is qcow2 with backing, which have "unallocated" region,
> > which is
> > backed by actual data in backing file.
>
> Come on now.
>
> > So, this region will be reported as not allocated and will be skipped by
> > any copying
> > loop using block-status? Is it a bug of BDRV_BLOCK_RAW itself? Or I don't
> > understand
> > something..
>
> I think what you don’t understand is that if you have a vpc file inside
> of a qcow2 file, you’re doing basically everything wrong. ;-)
>
> But maybe we should drop BDRV_BLOCK_RAW... Does it do anything good for
> us in the raw driver? Shouldn’t it too just return DATA | RECURSE?
DATA | RECURSE is still DATA, i.e. marks the block as allocated. If you
do that unconditionally, we will never consider a block unallocated.
RECURSE doesn't undo this, the only thing it might do is settting ZERO
additionally.
So I would say unconditionally returning DATA | RECURSE is almost always
wrong.
Kevin
signature.asc
Description: PGP signature