0cffb504e7
With the drive-backup QMP command, upstream QEMU uses a drained section for the source drive when creating the backup job. Do the same here to avoid subtle bugs. There, the drained section extends until after the job is started, but this cannot be done here for multi-disk backups (could at most start the first job). The important thing is that the cbw (copy-before-write) node is in place and the bcs (block-copy-state) bitmap is initialized, which both happen during job creation (ensured by the "block/backup: move bcs bitmap initialization to job creation" PVE patch). One such bug is one reported in the community forum [0], where using a drive with iothread can lead to an overlapping block-copy request and consequently an assertion failure. The block-copy code relies on the bcs bitmap to determine if a request for a certain range can be created. Each time a request is created, it resets the bcs bitmap at that range to indicate that it's being handled. The duplicate request can happen as follows: Thread A attaches the cbw node Thread B creates a request and resets the bitmap at that range Thread A clears the bitmap and merges it with the PBS bitmap The merging can lead to the bitmap being set again at the range of the previous request, so the block-copy code thinks it's fine to create a request there. Thread B creates another requests at an overlapping range before the other request is finished. The drained section ensures that nothing else can interfere with the bcs bitmap between attaching the copy-before-write block node and initialization of the bitmap. [0]: https://forum.proxmox.com/threads/133149/ Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> |
||
|---|---|---|
| debian | ||
| keycodemapdb | ||
| qemu@f7f686b61c | ||
| .gitignore | ||
| .gitmodules | ||
| backup.txt | ||
| Makefile | ||
| vma_spec.txt | ||