From: Max Reitz <mreitz@redhat.com>
To: Alyssa Milburn <fuzzie@fuzzie.org>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] blockdev: Unset temporary flag when changing medium.
Date: Sat, 6 Feb 2016 15:15:29 +0100 [thread overview]
Message-ID: <56B60001.2080509@redhat.com> (raw)
In-Reply-To: <20160206134717.GM9530@li141-249.members.linode.com>
[-- Attachment #1: Type: text/plain, Size: 2934 bytes --]
On 06.02.2016 14:47, Alyssa Milburn wrote:
> On Sat, Feb 06, 2016 at 02:04:23PM +0100, Max Reitz wrote:
>> On 04.02.2016 18:36, Alyssa Milburn wrote:
>>> This avoids a 'change' command from the monitor unlink()ing the new
>>> file if the bdrv was previously snapshotted.
>>>
>>> Signed-off-by: Alyssa Milburn <fuzzie@fuzzie.org>
>>> ---
>>> blockdev.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/blockdev.c b/blockdev.c
>>> index be4ca44..d39c2e6 100644
>>> --- a/blockdev.c
>>> +++ b/blockdev.c
>>> @@ -2514,6 +2514,7 @@ void qmp_blockdev_change_medium(const char *device, const char *filename,
>>> }
>>>
>>> bdrv_flags = blk_get_open_flags_from_root_state(blk);
>>> + bdrv_flags &= ~BDRV_O_TEMPORARY;
>>>
>>> if (!has_read_only) {
>>> read_only = BLOCKDEV_CHANGE_READ_ONLY_MODE_RETAIN;
>>>
>>
>> This patch is correct (thanks!), but I think we want to unset even more
>> flags, namely BDRV_O_SNAPSHOT, BDRV_O_NO_BACKING, and BDRV_O_PROTOCOL.
>
> Thanks. I posted an updated patch with this change (but of course, this is a
> trivial patch anyway). It's not entirely clear to me which flags should(n't)
> be preserved and where to do that.
Ideally, none would be. You'd use blockdev-add and
x-blockdev-{remove,insert}-medium to do the change manually, and specify
all the options for the new BlockDriverState using blockdev-add.
The BlockBackend's root state is just a legacy hack because the 'change'
command preserved some flags and other options of the old medium for the
new one that is inserted.
So I think we should preserve as many flags as possible, unless
something weird might happen which one doesn't want, and so I guessed
for each of the flags if they'd do something I'd not expect when issuing
a change command:
- O_TEMPORARY: Would delete the new medium's file.
- O_SNAPSHOT: Would silently create a snapshot over the new medium
(actually, apparently it does not, but this is a bug...).
- O_NO_BACKING: Would not open the backing chain for the new image.
- O_PROTOCOL: Would ignore the format of the new file and just open it
raw.
While I personally wouldn't like any flag to be inherited from the
previous medium, the rest doesn't look like it would do much harm. If
one doesn't like that the cache is fully inherited, they just have to
use blockdev-add and x-blockdev-{remove,insert}-medium.
> Since the snapshotted file is part of a
> chain (and the original flags are "correct") I wondered if this might not be
> the ideal fix, but it seems safe/sane to do it here.
Well, another place to do it is in blk_update_root_state() or inside of
blk_get_open_flags_from_root_state(). But I don't think it matters
because this is the only place that calls that function (and this is not
supposed to change, because it is just legacy handling anyway).
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
prev parent reply other threads:[~2016-02-06 14:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 17:36 [Qemu-devel] [PATCH] blockdev: Unset temporary flag when changing medium Alyssa Milburn
2016-02-06 13:04 ` [Qemu-devel] [Qemu-block] " Max Reitz
2016-02-06 13:47 ` Alyssa Milburn
2016-02-06 14:15 ` Max Reitz [this message]
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=56B60001.2080509@redhat.com \
--to=mreitz@redhat.com \
--cc=armbru@redhat.com \
--cc=fuzzie@fuzzie.org \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).