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

[Kevin Wolf <kwolf@redhat.com>]

Am 06.03.2026 um 11:20 hat Hanna Czenczek geschrieben:
> On 04.03.26 17:13, Kevin Wolf wrote:
> > 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?
> 
> First, bdrv_co_write_req_prepare() requires !BDRV_O_NO_IO and the RESIZE
> permission.

Ah, I wasn't aware that truncate requires !BDRV_O_NO_IO. It's not what I
would intuitively call I/O, but it's also justifiable because it changes
the result of reading some blocks.

The part where things start to feel questionable is with the way
qcow2_co_create() uses truncate. It doesn't actually want to truncate
the image (especially with an existing data file), but just allocate the
metadata for the full image size.

If the problem is just bdrv_co_write_req_prepare(), would a request flag
for the truncate solve it without having to introduce two global BDS
flags that can never be set by the user? BDRV_REQ_NO_DATA_IO or
something?

> We could bypass this by calling qcow2_co_truncate() instead of
> blk_co_truncate().  Feels wrong to me to pass BDRV_O_NO_IO and
> !BDRV_O_RESIZE to blk_co_new_open() when we actually kind of want those
> things and just bypass the BB to get them, but only morally wrong. Not
> technically wrong.
> 
> Bigger problem: BDRV_O_NO_IO makes qcow2 skip opening the data-file
> altogether.  So we would need to distinguish between qemu-img info and
> this case somehow.

Do we need to have it opened, except for preallocation, which can't set
BDRV_O_NO_IO anyway?

> (I also thought maybe the bdrv_co_truncate() in qcow2_co_truncate() might be
> a problem with data-file inheriting BDRV_O_NO_IO, but because
> qcow2_co_create() puts in a pre-opened BDS (without the flag set), that part
> works.)

We should probably skip truncating the data file for BDRV_REQ_NO_DATA_IO
and we want to make the image the same size as the data file anyway, no?
I don't think we have the intention to actually resize the data file, do
we?

Kevin