[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] qemu-img rebase: Fix for undersized backing fil
Re: [Qemu-devel] [PATCH] qemu-img rebase: Fix for undersized backing files
Wed, 07 Dec 2011 13:15:51 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0
Am 07.12.2011 13:06, schrieb Stefan Hajnoczi:
> On Wed, Dec 7, 2011 at 12:02 PM, Kevin Wolf <address@hidden> wrote:
>> Am 07.12.2011 12:50, schrieb Stefan Hajnoczi:
>>> On Wed, Dec 7, 2011 at 11:45 AM, Kevin Wolf <address@hidden> wrote:
>>>> Backing files may be smaller than the corresponding COW file. When
>>>> reading directly from the backing file, qemu-img rebase must consider
>>>> this and assume zero sectors after the end of backing files.
>>>> Signed-off-by: Kevin Wolf <address@hidden>
>>>> qemu-img.c | 42 +++++++++++++++++++++++++++++++++---------
>>>> 1 files changed, 33 insertions(+), 9 deletions(-)
>>> Reviewed-by: Stefan Hajnoczi <address@hidden>
>>> It almost feels like we want a bdrv_read() variation that does the
>>> zeroing beyond end of image instead of duplicating this.
>> Almost. If we have a third user, it's probably worth it.
>> Actually, if we make a bdrv_co_readv_backing() instead of a synchronous
>> one, qcow2 would be the third user (and maybe VMDK could use it, too).
>> That would require moving qemu-img into a coroutine first, which I think
>> you wanted to do anyway?
> If we can make qemu-img the last user of synchronous interfaces then
> it would be nice to convert it. Right now I'm happy that we're
> solidifying coroutines and converting synchronous hardware emulation,
> hopefully we'll get to the point where there is no real reason to keep
> the synchronous API around anymore.
The point is, if I were to introduce a bdrv_co_readv_backing() function,
I certainly wouldn't like to add all the bdrv_(aio_)read/write emulation
code for it, too.