[Top][All Lists]

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

Re: [PATCH for-4.2?] block/qcow2-bitmap: fix crash bug in qcow2_co_remov

From: Eric Blake
Subject: Re: [PATCH for-4.2?] block/qcow2-bitmap: fix crash bug in qcow2_co_remove_persistent_dirty_bitmap
Date: Fri, 6 Dec 2019 13:48:53 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 12/6/19 1:02 PM, John Snow wrote:

I'm afraid that the only thing is not remove persistent bitmaps, which
were never synced to the image. So, instead the sequence above, we need

1. create persistent bitmap A
2. shutdown vm
3. start vm
4. create persistent bitmap B
5. remember, that we want to remove bitmap B after vm shutdown
    some other operations
6. vm shutdown
7. start vm in stopped mode, and remove all bitmaps marked for removing
8. stop vm

But, I think that in real circumstances, vm shutdown is rare thing...

Part of me wonders if we would have detected this MUCH sooner if I had gotten my wish of having the qcow2 metadata updated on creation of any persistent bitmap (not actually writing out the bitmap itself, just updating the bitmap table to mark that there is a new persistent inconsistent bitmap), so that a) qemu-img info -U can see the persistent bitmap's existence, and b) an unexpected abrupt crash of qemu does not lose the existence of the bitmap. At the time I raised the question, the push-back at the time was a desire to minimize writes to the qcow2 metadata at all costs, warranting our current extreme code contortions to keep persistent bitmaps were kept in memory only until VM shutdown. But had we been doing it, we would spot problems like this without having to do VM shutdown, and our code might actually be simpler than our current contortions. Maybe we should still revisit that decision (of course, that question is independent of this patch, and therefore 5.0 material at earliest).

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

reply via email to

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