qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 6/6] nbd: forbid use of frozen bitmaps


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v4 6/6] nbd: forbid use of frozen bitmaps
Date: Wed, 3 Oct 2018 07:31:21 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 10/2/18 6:02 PM, John Snow wrote:
Whether it's "locked" or "frozen", it's in use and should
not be allowed for the purposes of this operation.

Signed-off-by: John Snow <address@hidden>
---
  nbd/server.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/nbd/server.c b/nbd/server.c
index c3dd402b45..940b7aa0cd 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -2478,8 +2478,8 @@ void nbd_export_bitmap(NBDExport *exp, const char *bitmap,
          return;
      }
- if (bdrv_dirty_bitmap_qmp_locked(bm)) {
-        error_setg(errp, "Bitmap '%s' is locked", bitmap);
+    if (bdrv_dirty_bitmap_user_locked(bm)) {
+        error_setg(errp, "Bitmap '%s' is in use", bitmap);

Again, I'm not sure about this. A locked bitmap is unchanging. A frozen bitmap is split, and might change when the split is resolved, so we are correct that we cannot tolerate a frozen bitmap. But if locking were changed to a refcount instead of a bool, I don't see why we have to forbid a locked bitmap. Then again, as in 5/6, the user can work around this limitation by cloning a locked bitmap into an unlocked temporary one, where we are trading ease of maintenance for a bit more user effort.

Weak Reviewed-by: Eric Blake <address@hidden>

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



reply via email to

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