15.12.2017 19:38, Max Reitz wrote:
Hi everyone,
Kevin, Markus, and me had a small personal meeting over the last 1.5
days and discussed a couple of things about the block layer and its QAPI
entanglements.
Here's a rather rough sketch on what we talked about:
[...]
== Single block job for backup/commit/mirror (blockdev-copy) ==
- Special things:
- mirror: Ready state and block-job-complete
- mirror: Always replaces some node by the target
- backup: copy before write and synchronous
(mirror/commit are copy after write and asynchronous (except
active-mirror))
- backup: Has @compressed, that may not work with mirror right now
(because block drivers assume you only write once)
- commit: Resizes target if smaller than source
- commit: Does not share write permissions, maybe because it doesn't
want to use a dirty bitmap (a unified job would just use a dirty
bitmap so then it could just generally share write permissions)
- active commit: Can read from source even if the backing chain is
garbage because of the ongoing commit (mirror) job
- block_job_add_bdrv() on nearly whole backing chain so that
READ_CONSISTENT is not being shared
- non-active commit: Write target's (base's) filename into all of
source's (top's) overlays as their backing filename
At least some of these differences would require blockdev-copy runtime
options.
blockdev-copy runtime parameters:
- everything blockdev-mirror has, plus
- @compressed? -- could be done as a block filter that converts normal
writes to compressed writes
- Some option to suppress node replacement
(in theory you could put block-job-finalize and bdrv_reopen into a
transaction to do that replacement yourself)
- Some option to suppress READY event and complete automatically
(compatibility to backup and non-active commit)
- Options to control the exact copying behavior (before/after write,
active/passive)
also, I think, for backup we need options to control the following:
- it there is a write notifier, which waits for copy, if copy fails,
what to do:
fail guest write or fail the backup?
- should we handle guest writes when block-job is paused (now they are
handled)
(passive before-write is impossible)
- Option to resize target if smaller than source
(maybe just internal and not visible in the interface)
(compatibility to block-commit)
- Several other commit thingies (like permissions) which can be
automatically deduced and set if the target is in source's backing
chain
- Option to specify the target's filename (this is written into all
overlays of @to_replace as their backing filename; if omitted, the
filename QEMU knows will be used)
--
Best regards,
Vladimir
