On 24.10.2016 13:35, Vladimir Sementsov-Ogievskiy wrote:
It's not a real problem, but it does take time, and I maintain that
24.10.2016 13:32, Vladimir Sementsov-Ogievskiy пишет:
21.10.2016 22:58, Max Reitz пишет:
On 21.10.2016 17:34, Vladimir Sementsov-Ogievskiy wrote:
You don't need to free any bitmaps when opening the file, and you
07.10.2016 22:44, Max Reitz пишет:
On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
This flag means that the bitmap is now in use by the software or
successfully saved. In any way, with this flag set the bitmap
be considered inconsistent and should not be loaded.
With current implementation this flag is never set, as we just
bitmaps from the image after loading. But it defined in qcow2
must be handled. Also, it can be used in future, if async
bitmap loading/saving are implemented.
We also remove in-use bitmaps from the image on open.
Signed-off-by: Vladimir Sementsov-Ogievskiy
block/qcow2-bitmap.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
Don't you want to make use of this flag? It would appear useful to
you just marked autoload bitmaps as in_use instead of deleting
the image when it's opened and then overwrite them when the
And what is the use of it?
need to allocate any new bitmap space when closing it.
As bitmaps are sparce in file, I need to allocate new space when
closing. Or free it...
Is it a real problem to reallocate space in qcow2? If so, to minimaze
allocations, I will have to make a list of clusters of in_use
close, and then save current bitmaps to these clusters (and allocated
some additional clusters, or free extra clusters).
time it doesn't need to take because you can just use the in_use flag.
I wouldn't worry about reusing clusters of other bitmaps. Of course we
can do that later on in some optimization but not now.
I just mean the basic case of some auto-loaded bitmap that is not being
deleted while the VM is running and is just saved back to the image
once it is closed. I don't expect that users will always consume all of
the auto-loaded bitmaps while the VM is active...
Also, if I don't free them on open, I'll have to free them on
bdrv dirty bitmap..
Yes, so? That takes time, but that is something the user will probably
expect. I wouldn't expect opening of the file to take that time.
Overall, it doesn't matter time-wise whether you free the bitmap data
when opening the image file or when the dirty bitmap is actually
by the user or when the image file is closed. Just setting the single
in_use flag for all of the auto-loaded bitmaps will basically not take
On the other hand, as soon as just a single auto-loaded bitmap survives
a VM (or qemu-img) invocation, you will very, very likely safe at least
some time because writing the bitmap to the disk can reuse at least
of the existing clusters.