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 <[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?
First, bdrv_co_write_req_prepare() requires !BDRV_O_NO_IO and the RESIZE
permission. 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.
(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.)
Hanna
