qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] bdrv_reopen() and backing images


From: Kevin Wolf
Subject: Re: [Qemu-block] bdrv_reopen() and backing images
Date: Wed, 17 Aug 2016 17:19:06 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 17.08.2016 um 13:51 hat Alberto Garcia geschrieben:
> Hi all,
> 
> we have already discussed this in the past: calling bdrv_reopen() has
> the side effect of putting the whole backing chain of the specified
> BDS in read-only mode.
> 
> This made block-commit fail in the past, and we worked around the
> problem by changing the order in which the images were reopened in
> commit_start():
> 
> 3db2bd5508c86a1605258 commit: reopen overlay_bs before base
> 
> But I would like to fix bdrv_reopen() properly. From what I can see
> the situation is that bdrv_backing_options() forces all backing BDSs
> to be opened without the BDRV_O_RDWR flag, which makes sense when you
> open an image for the first time, but not so much when you reopen it.
> 
> One way to deal with this would be by removing the BDRV_O_RDWR flag in
> bdrv_open_backing_file() or so instead of bdrv_backing_options(), but
> that doesn't seem to be the best option.
> 
> The other possibility that I see is modifying bdrv_reopen() instead. I
> actually don't see why the whole set of children of a BDS needs to
> be reopened even when none of their options is changing, and why
> inherit_options() needs to be called for each children (instead of
> keeping its existing flags).

The wanted behaviour is, like with all other options, that the option
stays as it is if it was set explicitly on the node, and to be updated
if it was inherited from the parent node.

I know that we do get this behaviour e.g. for cache modes. It might be
that the (hopefully only) reason why we can't have it for read-only yet
is that the read-only option is still passed in flags rather than the
QDict.

Converting it to be a "normal" option using the QDict should fix the
problem then.

Kevin



reply via email to

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