qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for-5.1] qcow2: Don't open images with a backing file and the


From: Alberto Garcia
Subject: Re: [PATCH for-5.1] qcow2: Don't open images with a backing file and the data-file-raw bit
Date: Fri, 19 Jun 2020 13:06:17 +0200
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Fri 19 Jun 2020 09:57:27 AM CEST, Max Reitz wrote:
>> If two images have the same contents but then you compare them
>> changing the backing file of one of them you can also get a content
>> mismatch. How is this different?
>
> It’s different in that files with data-file-raw can’t have backing
> files at all.  So maybe users shouldn’t be allowed to give them
> backing files at runtime either.

I understand that. Ideally it should be forbidden. Perhaps that could be
fixed by turning drv->supports_backing into a function.

My point however is that forcing a different backing file is something
that is going to cause breakage unless the user really knows that
they're doing. And we don't generally forbid that, we just let the user
take responsibility. So I'm not too worried about this case.

> Or at least, if we have data-file-raw, *all* data visible on such an
> image should be taken from the raw data file, never from any backing
> file.

It should be easy to handle in qcow2_co_preadv_part() and
qcow2_co_copy_range_from(), but it feels hackish and error prone.

> With preallocation, we’d ensure that we always take all data from the
> raw data file.  So we’d always ignore any potential backing file.

Preallocation has its problems (and we would also have to handle it
differently if there are subclusters, but I think that should be
easy). But I don't have a strong opinion.

Berto



reply via email to

[Prev in Thread] Current Thread [Next in Thread]