11.03.2019 19:18, Eric Blake wrote: > On 3/5/19 5:43 PM, John Snow wrote: >> This series aims to enable block resizes when persistent bitmaps are >> in use. The basic approach here is to recognize that we now load all >> persistent bitmaps in memory, and so we can rely on in-memory resizes >> and then flush the changed metadata back to disk. >> >> One part that is potentially now quite strange is that bitmap resizes >> may happen twice: once during the qcow2 resize event only if persistent >> bitmaps are found, and then again as part of the generic resize callback >> event whether or not we have any persistent bitmaps. >> >> The second round is required if we are not using qcow2 or we have only >> transient bitmaps. The first round is required as we wish to flush the >> bitmaps back to disk atomically with the qcow2 resize to avoid violating >> our invariants for the bitmap metadata which is checked in many places. >> >> This is harmless; hbitmap_truncate will recognize the second round as >> a no-op. > > FWIW - I have not yet reviewed this series closely, but I think it would > be wise to get this initial cut in before softfreeze (we can make > further tweaks to fix bugs in assumptions during rc1 and rc2, but it's a > lot harder to add the series at all if it misses softfreeze). >
I still not convinced that we need bitmap flushing. I think (and Den supports me) that it's a bad idea. It makes things more difficult without a reason, except improving debugging with --force-share which should never be used in production. Bitmaps are stored in qcow2_inactivate() which is true place for flushing caches. -- Best regards, Vladimir
