From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
To: qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, Hanna Czenczek <hreitz@redhat.com>,
Kevin Wolf <kwolf@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>,
Eric Blake <eblake@redhat.com>,
"Denis V. Lunev" <den@virtuozzo.com>,
andrey.drobyshev@virtuozzo.com
Subject: [BUG, RFC] Base node is in RW after making external snapshot
Date: Wed, 24 Apr 2024 21:00:08 +0300 [thread overview]
Message-ID: <fa7a3d64-aa65-444b-8e65-87a64e47684a@virtuozzo.com> (raw)
Hi everyone,
When making an external snapshot, we end up in a situation when 2 block
graph nodes related to the same image file (format and storage nodes)
have different RO flags set on them.
E.g.
# ls -la /proc/PID/fd
lrwx------ 1 root qemu 64 Apr 24 20:14 12 -> /path/to/harddisk.hdd
# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}'
--pretty | egrep '"node-name"|"ro"'
"ro": false,
"node-name": "libvirt-1-format",
"ro": false,
"node-name": "libvirt-1-storage",
# virsh snapshot-create-as VM --name snap --disk-only
Domain snapshot snap created
# ls -la /proc/PID/fd
lr-x------ 1 root qemu 64 Apr 24 20:14 134 -> /path/to/harddisk.hdd
lrwx------ 1 root qemu 64 Apr 24 20:14 135 -> /path/to/harddisk.snap
# virsh qemu-monitor-command VM '{"execute": "query-named-block-nodes"}'
--pretty | egrep '"node-name"|"ro"'
"ro": false,
"node-name": "libvirt-2-format",
"ro": false,
"node-name": "libvirt-2-storage",
"ro": true,
"node-name": "libvirt-1-format",
"ro": false, <--------------
"node-name": "libvirt-1-storage",
File descriptor has been reopened in RO, but "libvirt-1-storage" node
still has RW permissions set.
I'm wondering it this a bug or this is intended? Looks like a bug to
me, although I see that some iotests (e.g. 273) expect 2 nodes related
to the same image file to have different RO flags.
bdrv_reopen_set_read_only()
bdrv_reopen()
bdrv_reopen_queue()
bdrv_reopen_queue_child()
bdrv_reopen_multiple()
bdrv_list_refresh_perms()
bdrv_topological_dfs()
bdrv_do_refresh_perms()
bdrv_reopen_commit()
In the stack above bdrv_reopen_set_read_only() is only being called for
the parent (libvirt-1-format) node. There're 2 lists: BDSs from
refresh_list are used by bdrv_drv_set_perm and this leads to actual
reopen with RO of the file descriptor. And then there's reopen queue
bs_queue -- BDSs from this queue get their parameters updated. While
refresh_list ends up having the whole subtree (including children, this
is done in bdrv_topological_dfs()) bs_queue only has the parent. And
that is because storage (child) node's (bs->inherits_from == NULL), so
bdrv_reopen_queue_child() never adds it to the queue. Could it be the
source of this bug?
Anyway, would greatly appreciate a clarification.
Andrey
next reply other threads:[~2024-04-24 18:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 18:00 Andrey Drobyshev [this message]
2024-05-10 19:29 ` [BUG, RFC] Base node is in RW after making external snapshot Andrey Drobyshev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa7a3d64-aa65-444b-8e65-87a64e47684a@virtuozzo.com \
--to=andrey.drobyshev@virtuozzo.com \
--cc=den@virtuozzo.com \
--cc=eblake@redhat.com \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.