Why Overlaybd for Virtual Machines - #439
Conversation
| chain carries its own table — each covering the full virtual disk, | ||
| because any guest block may resolve to any snapshot — and its own | ||
| cache in the hypervisor. A 30-snapshot chain does not have an index | ||
| problem of 12.5 MB; it has an index problem of 30 × 12.5 MB, with |
There was a problem hiding this comment.
The 12.5 MiB figure assumes that L2 tables covering the entire 100 GiB address space are allocated. qcow2 allocates L2 tables lazily; an untouched snapshot layer may contain only its small L1 table, while reads for absent L2 regions fall through to the backing file. Therefore, 30 × 12.5 MiB is a worst-case scenario for widely populated layers, not the general metadata cost of a 30-layer chain
There was a problem hiding this comment.
Yes, the "100 GB" is actual amount of data, not disk size.
| wide because they carry more than an offset: flag bits mark each | ||
| cluster as copied, zero, or compressed, and the offset field | ||
| addresses an exabyte-scale file. QEMU's default L2 cache is about | ||
| 1 MB — some 8% of the table — so the operator chooses between |
There was a problem hiding this comment.
The stated QEMU L2 cache default is outdated. Current QEMU defaults l2-cache-size to 32 MiB on Linux and 8 MiB on non-Linux platforms when cache-size is not specified. Therefore, the claim that the default cache covers only 8% of a 12.5 MiB table is not true for current QEMU; the default Linux cache is large enough to hold that fully populated table. Please either scope this statement to a specific older QEMU version with a citation, or update the numbers and the resulting cache-pressure argument.
Ref: https://www.qemu.org/docs/master/system/qemu-manpage.html
|
|
||
| ## The Dilemma: Index Memory Overhead vs Copy-on-Write Overhead | ||
|
|
||
| Every fixed-granularity table sits on the same trade-off curve. Table |
There was a problem hiding this comment.
I’m not deeply familiar with VHDX internals, so I may be missing an implementation detail here. However, the VHDX specification appears to allow a differencing disk to use PAYLOAD_BLOCK_PARTIALLY_PRESENT, with a sector bitmap indicating whether each sector should be read from the child or its parent. This seems to mean that a small write does not necessarily require copying the rest of the payload block from the parent. Would it be more accurate to distinguish mandatory copy-up from allocation or space amplification here?
There was a problem hiding this comment.
Yes, partial block helps.
| tooling (`Merge-VHD`, Edit Disk) to collapse differencing-disk | ||
| chains back down. | ||
|
|
||
| - **QEMU** provides `block-commit` and `block-stream` in |
There was a problem hiding this comment.
I don’t think block-stream and block-commit are qemu-img commands. They appear to be live block operations exposed through QMP, while qemu-img provides offline commands such as commit and rebase. Could this be changed to say that QEMU provides these operations through QMP and link to the live block operations documentation instead?
References:
fuweid
left a comment
fuweid
left a comment
There was a problem hiding this comment.
LGTM
Please squash into one commit and signoff
2 participants
What this PR does / why we need it:
why overlaybd for VMs
preview: https://lihuiba.github.io/overlaybd/#/vmimg