block: qcow: Fix QCOW2 thread safety for multiple virtio queues - #7661
Merged
Merged
Conversation
Add stress tests for QCOW2 with >=8 virtio queues to verify thread safety of multiqueue concurrent disk access: - parallel dd writes - 4 readers + 4 writers mixed I/O - overlay with backing file - random 4K writes - parallel small writes + fsync - mkdir/touch/rm/rename metadata operations Signed-off-by: Anatol Belski <[email protected]>
Wrap QcowFile in Arc<Mutex<>> to ensure thread safety when multiple virtio queues access the same QCOW2 image concurrently. Previously, each queue received its own QcowSync instance via new_async_io() that shared the underlying QcowFile through Clone. However, cloned QcowFile instances share internal mutable state (L2 cache, reference counts, file seek position) without synchronization, leading to data corruption under concurrent I/O. This change serializes all QCOW2 operations through a mutex, which ensures correctness at the cost of parallelism. A more performant solution would require separating metadata locking from actual I/O operations, tracked in cloud-hypervisor#7560. Related: cloud-hypervisor#7560 Signed-off-by: Anatol Belski <[email protected]>
rbradford
approved these changes
Feb 3, 2026
This was referenced Feb 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes data corruption when using QCOW2 images with
num_queues > 1.When virtio-block is configured with multiple queues, each queue gets its own
QcowSyncinstance that shares the underlyingQcowFilethroughClone. The cloned instances share mutable file position but stay out of sync with metadata, leading to cache corruption under concurrent I/O.Issue #7560 carries plans and a discussion targeting a proper refactoring for the block crate. As an immediate fix, wrapping
QcowFileinArc<Mutex<>>to serialize all QCOW2 operations seems the simplest solution. This approach has obvious performance downsides for multiqueue configurations, however:num_queues=1is negligibleWhile introducing serialization ahead of a proper refactoring is not ideal, the current data corruption makes this a necessary intermediate step to provide a working multiqueue QCOW2 implementation.
Multiple stress tests have been added: parallel writes, mixed read/write, backing file operations, random 4K I/O, fsync storms, and metadata operations.
Fixes #7660