qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH v3] block: maintain persistent disabled bitmaps


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [PATCH v3] block: maintain persistent disabled bitmaps
Date: Fri, 2 Feb 2018 19:29:45 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

02.02.2018 19:18, Eric Blake wrote:
On 02/02/2018 10:07 AM, Vladimir Sementsov-Ogievskiy wrote:
To maintain load/store disabled bitmap there is new approach:

  - deprecate @autoload flag of block-dirty-bitmap-add, make it ignored
  - store enabled bitmaps as "auto" to qcow2
  - store disabled bitmaps without "auto" flag to qcow2
  - on qcow2 open load "auto" bitmaps as enabled and others
    as disabled (except in_use bitmaps)

Also, adjust iotests 165 and 176 appropriately.

Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
---
+++ b/qemu-doc.texi
@@ -2749,6 +2749,13 @@ used and it will be removed with no replacement.
  The ``convert -s snapshot_id_or_name'' argument is obsoleted
  by the ``convert -l snapshot_param'' argument instead.
address@hidden QEMU Machine Protocol (QMP) commands
+
address@hidden block-dirty-bitmap-add "autoload" parameter (since 2.12.0)
+
+"autoload" parameter is now ignored. All bitmaps are automatically loaded
+from qcow2 image.
Won't later patches be adding the ability to enable/disable bitmaps,
which then affects whether they are autoloaded?  So we don't forget to
revisit this text in that patch, a better wording might be:

The "autoload" parameter is ignored; all enabled persistent dirty
bitmaps are automatically loaded from a qcow2 image, regardless of the
initial setting requested in this parameter.


hmm.. no. all bitmaps are loaded, even disabled ones. Before this patch there is
no way to have disabled bitmap in qemu (by loading or by creating).
After the patch, we have a theoretical way of creating such bitmap in qcow2 image, then
it will be loaded as disabled.

Also, we can store bitmap with persistent=true and autoload=false before this patch, and there is no way to load this bitmap before this patch, but after this patch it will be loaded as disabled.




@@ -667,19 +662,6 @@ bool bdrv_has_readonly_bitmaps(BlockDriverState *bs)
  }
/* Called with BQL taken. */
-void bdrv_dirty_bitmap_set_autoload(BdrvDirtyBitmap *bitmap, bool autoload)
-{
-    qemu_mutex_lock(bitmap->mutex);
-    bitmap->autoload = autoload;
-    qemu_mutex_unlock(bitmap->mutex);
-}
-
-bool bdrv_dirty_bitmap_get_autoload(const BdrvDirtyBitmap *bitmap)
-{
-    return bitmap->autoload;
-}
Will later patches be reintroducing these functions for learning which
bitmaps are enabled/disabled?  But I'm okay with deleting them in this
patch, even if that is more churn.


no, actually the aim of the patch is to drop buggy relation between autoload qmp parameter and auto qcow2 flag (which is more like "enabled" then "autoload"). Look at "Reasoning" in head
letter for details.

--
Best regards,
Vladimir




reply via email to

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