From: Kashyap Chamarthy <kchamart@redhat.com>
To: Alberto Garcia <berto@igalia.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
Max Reitz <mreitz@redhat.com>
Subject: Re: [RFC PATCH 0/2] Allow changing bs->file on reopen
Date: Fri, 15 Jan 2021 14:31:54 +0100 [thread overview]
Message-ID: <20210115133154.GA531618@paraplu> (raw)
In-Reply-To: <cover.1610715661.git.berto@igalia.com>
[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]
On Fri, Jan 15, 2021 at 02:02:36PM +0100, Alberto Garcia wrote:
> Hi,
Hi,
> during the past months we talked about making x-blockdev-reopen stable
> API, and one of the missing things was having support for changing
> bs->file. See here for the discusssion (I can't find the message from
> Kashyap that started the thread in the web archives):
>
> https://lists.gnu.org/archive/html/qemu-block/2020-10/msg00922.html
Yeah, I noticed that too -- seems like it got "lost" somehow :-(. For
the record, I've attached here the original e-mail I sent on 06-OCT-2020
that started the above thread.
Thanks for working on this!
> I was testing this and one of the problems that I found was that
> removing a filter node using this command is tricky because of the
> permission system, see here for details:
>
> https://lists.gnu.org/archive/html/qemu-block/2020-12/msg00092.html
>
> The good news is that Vladimir posted a set of patches that changes
> the way that permissions are updated on reopen:
>
> https://lists.gnu.org/archive/html/qemu-block/2020-11/msg00745.html
>
> I was testing if this would be useful to solve the problem that I
> mentioned earlier and it seems to be the case so I wrote a patch to
> add support for changing bs->file, along with a couple of test cases.
>
> This is still an RFC but you can see the idea.
>
> These patches apply on top of Vladimir's branch:
>
> git: https://src.openvz.org/scm/~vsementsov/qemu.git
> tag: up-block-topologic-perm-v2
>
> Opinions are very welcome!
>
> Berto
>
> Alberto Garcia (2):
> block: Allow changing bs->file on reopen
> iotests: Update 245 to support replacing files with x-blockdev-reopen
>
> include/block/block.h | 1 +
> block.c | 61 ++++++++++++++++++++++++++++++++++++++
> tests/qemu-iotests/245 | 61 +++++++++++++++++++++++++++++++++++---
> tests/qemu-iotests/245.out | 4 +--
> 4 files changed, 121 insertions(+), 6 deletions(-)
>
> --
> 2.20.1
>
--
/kashyap
[-- Attachment #2: x-blockdev-reopen-thread_06OCT2020.txt --]
[-- Type: text/plain, Size: 2097 bytes --]
Date: Tue, 6 Oct 2020 11:10:01 +0200
From: Kashyap Chamarthy <kchamart@redhat.com>
To: qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: berto@igalia.com, eblake@redhat.com
Subject: Plans to bring QMP 'x-blockdev-reopen' out of experimental?
Message-ID: <20201006091001.GA64583@paraplu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Hi, folks
If this was already discussed on the list, please point me to the
thread. I took a quick look at my local archives, I didn't find any,
besides patches to tests.
I learn that `x-blockdev-reopen` enables a couple of interesting use
cases:
(#) Allowing one to live-change the backing file to point to a different
location, with the target having content identical to original.
This one I was already familiar with.
(#) Yesterday I learnt another use case from Peter Krempa and Eric
Blake. Allow me to quote (paraphrasing) Eric's example from IRC.
E.g. we have (where 'overlay1' has a bitmap):
base <- overlay1
Then create a temporary snapshot (which results a bitmap being
created in 'overlay2', because 'overlay1' had one):
base <- overlay1 <- overlay2
If you want to do a `block-commit` to merge 'overlay2' back into
'overlay1', currently upstream QEMU does not merge the bitmap states
from 'overlay2' back into 'overlay1' properly. This current
limitation is because QEMU can't merge the bitmaps unless it can
reopen 'overlay1' [for read-write] _prior_ to doing the commit — but
the only way to do that is with `x-blockdev-reopen`.
- - -
From an old chat with Berto on #qemu, he was looking for some more
robust testing, before lifting it out of experimental mode, as it was a
rather complicated command to implement.
Currently, I see there are some 'qemu-iotests' that exercise
'x-blockdev-reopen': 155, 165, 245, and 248. What else kind of tests
can give more confidence?
(I personally don't have an urgent need for this, so I'm not trying to
rush anything. :-))
--
/kashyap
next prev parent reply other threads:[~2021-01-15 13:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 13:02 [RFC PATCH 0/2] Allow changing bs->file on reopen Alberto Garcia
2021-01-15 13:02 ` [RFC PATCH 1/2] block: " Alberto Garcia
2021-01-18 10:15 ` Vladimir Sementsov-Ogievskiy
2021-01-19 11:46 ` Alberto Garcia
2021-01-15 13:02 ` [RFC PATCH 2/2] iotests: Update 245 to support replacing files with x-blockdev-reopen Alberto Garcia
2021-01-15 13:31 ` Kashyap Chamarthy [this message]
2021-01-18 10:22 ` [RFC PATCH 0/2] Allow changing bs->file on reopen Vladimir Sementsov-Ogievskiy
2021-01-20 13:51 ` Alberto Garcia
2021-01-20 13:55 ` Vladimir Sementsov-Ogievskiy
2021-01-21 10:52 ` Kevin Wolf
2021-02-05 12:47 ` Alberto Garcia
2021-02-05 15:41 ` Kevin Wolf
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=20210115133154.GA531618@paraplu \
--to=kchamart@redhat.com \
--cc=berto@igalia.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/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.