On 3/22/21 9:41 AM, Vladimir Sementsov-Ogievskiy wrote: > 20.03.2021 12:32, Patrik Janoušek wrote: >> Current implementation of dirty bitmaps for raw format is very >> limited, because those bitmaps cannot be persistent. Basically it >> makes sense, because the raw format doesn't have space where could >> be dirty bitmap stored when QEMU is offline. This patch solves it >> by storing content of every dirty bitmap in separate file on the >> host filesystem. >> >> However, this only solves one part of the problem. We also have to >> store information about the existence of the dirty bitmap. This is >> solved by adding custom options, that stores all required metadata >> about dirty bitmap (filename where is the bitmap stored on the >> host filesystem, granularity, persistence, etc.). >> >> Signed-off-by: Patrik Janoušek<p...@patrikjanousek.cz> > > > Hmm. Did you considered other ways? Honestly, I don't see a reason for > yet another storing format for bitmaps. > > The task could be simply solved with existing features: > > 1. We have extenal-data-file feature in qcow2 (read > docs/interop/qcow2.txt). With this thing enabled, qcow2 file contains > only metadata (persistent bitmaps for example) and data is stored in > separate sequential raw file. I think you should start from it.
I didn't know about that feature. I'll look at it. In case I use NBD to access the bitmap context and qcow2 as a solution for persistent layer. Would the patch be acceptable? This is significant change to my solution and I don't have enought time for it at the moment (mainly due to other parts of my bachelor's thesis). I just want to know if this kind of feature is interesting to you and its implementation is worth my time. > > 2. If for some reason [1] doesn't work for you, you can anyway use an > empty qcow2 file to store bitmaps instead of inventing and > implementing new format of bitmaps storing. (Same as your approach, > you'll have a simple raw node, and additional options will say "load > bitmaps from this qcow2 file". But for such options we'll need good > reasons why [1] isn't enough. >
