Re: [PATCH 2/5] block: Introduce BDRV_O_NO_DATA_{WRITE,RESIZE}

[Kevin Wolf <kwolf@redhat.com>]

Am 04.03.2026 um 15:20 hat Hanna Czenczek geschrieben:
> On 02.03.26 15:30, Kevin Wolf wrote:
> > Am 05.02.2026 um 15:47 hat Hanna Czenczek geschrieben:
> > > Add BDS flags that prevent taking WRITE and/or RESIZE permissions on
> > > pure data (no metadata) children.  These are going to be used by qcow2
> > > during formatting, when we need write access to format the metadata
> > > file, but no write access to an external data file.  This will allow
> > > creating a qcow2 image for a raw image while the latter is currently in
> > > use by the VM.
> > > 
> > > Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
> > > ---
> > >   include/block/block-common.h | 11 +++++++++++
> > >   block.c                      | 15 +++++++++++++++
> > >   2 files changed, 26 insertions(+)
> > > 
> > > diff --git a/include/block/block-common.h b/include/block/block-common.h
> > > index c8c626daea..504f6aa113 100644
> > > --- a/include/block/block-common.h
> > > +++ b/include/block/block-common.h
> > > @@ -245,6 +245,17 @@ typedef enum {
> > >   #define BDRV_O_CBW_DISCARD_SOURCE 0x80000 /* for copy-before-write filter */
> > > +/*
> > > + * Promise not to write any data to pure (non-metadata-bearing) data storage
> > > + * children, so we don't need the WRITE permission for them.
> > > + * For image creation, formatting requires write access to the image, but not
> > > + * necessarily to its pure storage children.  This allows creating an image on
> > > + * top of an existing raw storage image that is already attached to the VM.
> > > + */
> > > +#define BDRV_O_NO_DATA_WRITE  0x100000
> > Can't we just use BDRV_O_NO_IO for this one? It is stricter because it
> > doesn't allow reading either, but I don't think image creation ever
> > requires reading from the image?
> 
> How would qcow2 set it?  It opens the qcow2 image, so it can only set the
> flag on the qcow2 BDS (via a BlockBackend), but BDRV_O_NO_IO needs to go on
> the data-file child.  Maybe we can construct the graph manually…? It would
> be quite painful, I imagine, but I haven’t tried yet.

Why should it go on the data-file child? The child permissions are
defined by the qcow2 node. If the caller promises not to do any I/O (and
I'm fairly sure that apart from preallocation, creating the image
doesn't involve any I/O on the qcow2 node, just on the primary child),
then qcow2 doesn't need any permissions on data-file.

Or am I missing a reason why BDRV_O_NO_IO can't be set for the qcow2
node?

Kevin