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 <[email protected]> > > > --- > > > 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
