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? > +/* Same as O_NO_DATA_WRITE, but for resizing */ > +#define BDRV_O_NO_DATA_RESIZE 0x200000 How does this differ from BDRV_O_RESIZE (apart from being negative)? Doesn't resizing always refer to the data part? Kevin
