Re: [PATCH v4 5/5] qcow2: repair a dirty image when it becomes writable

[Markus Armbruster <armbru@redhat.com>]

"Denis V. Lunev" <den@virtuozzo.com> writes:

> On 8/27/26 11:15, Markus Armbruster wrote:

[...]

>> We must not (re)open a dirty image read/write without cleaning it,
>> because writing to risks corruption, i.e. data loss.
>>
>> When we open a dirty image read/write, we can clean it without
>> inconveniencing the guest, because the guest cannot access it until
>> after open completes and we connect the newly open image.  Correct?
> correct.
>
>> When we reopen a read/only dirty image read/write, cleaning it *can*
>> affect the guest, as discussed above.
>>
>> As far as I can tell, all the trouble discussed above ultimately comes
>> from letting the guest work with read-only dirty images.  Why is that
>> useful?
>>
>> What are the use cases for opening dirty images read-only?
> Read only images usually comes in image chains (snapshots, backing
> stores). How RO image becomes dirty is very good question. May
> be this was due to QEMU stop/node crash during running commit.
>
> Why this is needed? VM should continue to start with dirty
> RO image. Doing maintenance at start? That is also problematic.
> At this moment we can face shared lock on base image (so called
> golden image scenario).

We can "do maintenance" during initial open proactively, or during
reopen read/write as needed.

In both cases, we risk delays that can make the guest hang.

Cleaning as needed might avoid some delays.  It can also shift delays
from QEMU startup (sometimes bad) to guest operation (commonly worse).

Cleaning as needed in its current state appears to violate
blockdev-reopen's contract: it breaks the transaction.  This feels like
a regression.

I think cleaning as needed poses challenges to management applications.
I figure sophisticated ones can make a reasonable choice between "clean
offline before you pass to QEMU" and "don't, and manage the delay on
reopen".  For less sophisticated ones, and also human users, all this
feels like a trap.

Have we considered dirty image open to require an "I'm sophisticated"
flag?

Anyway, this is how far I can take this.  Now the block layer
maintainers need to chime in.

[...]