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.
Hanna
+/* 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
