qemu-block
[Top][All Lists]
Advanced

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

[Qemu-block] bug in reopen arch


From: Vladimir Sementsov-Ogievskiy
Subject: [Qemu-block] bug in reopen arch
Date: Tue, 12 Jun 2018 21:57:18 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Hi all!

I've faced the following problem:

    1. create image with dirty bitmap, a.qcow2 (start qemu and run qmp
    command block-dirty-bitmap-add)

    2. run the following commands:

        qemu-img create -f qcow2 -b a.qcow2 b.qcow2 10M
        qemu-io -c 'write 0 512' b.qcow2
        qemu-img commit b.qcow2

    3. last command fails with the following output:

Formatting 'b.qcow2', fmt=qcow2 size=68719476736 backing_file=a.qcow2 cluster_size=65536 lazy_refcounts=off refcount_bits=16
wrote 512/512 bytes at offset 0
512 bytes, 1 ops; 0.0953 sec (5.243 KiB/sec and 10.4867 ops/sec)
qemu-img: #block397: Failed to make dirty bitmaps writable: Can't update bitmap directory: Operation not permitted
qemu-img: Block job failed: Operation not permitted


And problem is that children are reopened _after_ parent. But qcow2 reopen needs write access to its file, to write IN_USE flag to dirty-bitmaps extension.

I've tried to fix it as simple as:


diff --git a/block.c b/block.c
index cfe5e6080d..392b2941ac 100644
--- a/block.c
+++ b/block.c
@@ -2793,7 +2793,7 @@ static BlockReopenQueue *bdrv_reopen_queue_child(BlockReopenQueue *bs_queue,

     if (!bs_entry) {
         bs_entry = g_new0(BlockReopenQueueEntry, 1);
-        QSIMPLEQ_INSERT_TAIL(bs_queue, bs_entry, entry);
+        QSIMPLEQ_INSERT_HEAD(bs_queue, bs_entry, entry);
     } else {
         QDECREF(bs_entry->state.options);
         QDECREF(bs_entry->state.explicit_options);


But this breaks a lot of iotests. And looks like it is wrong idea, because permissions should be updated for parent first. We've faced and fixed similar problems with invalidation sequence. Reopen architecture differs with it's bs_queue.. Any ideas how to fix this?

Similar story with invalidation includes

commit 16e977d506bcc2d9f7daa4a9f7cc2b48536d9da6
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date:   Tue Jan 31 14:23:08 2017 +0300

    block: bdrv_invalidate_cache: invalidate children first

and

commit dafe096057373d95847e1c99c2fece34be9fc5bb
Author: Kevin Wolf <address@hidden>
Date:   Thu Nov 16 13:00:01 2017 +0100

    block: Fix permissions in image activation

--
Best regards,
Vladimir




reply via email to

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