Repository navigation
qemu: carry upstream's discard accounting for virtio-blk - #79
Merged
Merged
Conversation
QEMU 11.1.1's virtio-blk never starts accounting for a DISCARD, so query-blockstats reports 0 unmap operations however much a guest trims: the page-cache lab trimmed 1.1 GiB and saw 0 (run 36815822140), and could only see the trim in the overlay's allocation. Upstream fixed it in 331ce936c133 (master, 2026-09-11); no release has it yet, v11.1.2 included. This is that commit unchanged, to delete in the bump that brings it. A new QEMU binary, so a new machine fingerprint. The page-cache probe now fails when the guest's fstrim is not counted. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ns.yaml Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Validated on construct, lab run 36884702758 (boot:page-cache caches, this branch's QEMU 36883820118, variant=instead): after the guest's fstrim QEMU counts 10-12 unmap operations and 1123 MB, matching the ~1.1 GiB trimmed. The release QEMU counted 0 on the same probe (run 36881456066). |
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
1 participant
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.
QEMU 11.1.1's virtio-blk never starts accounting for a DISCARD (
virtio_blk_handle_discard_write_zeroescallsblock_acct_startonly for WRITE_ZEROES), soquery-blockstatsshowsunmap_operations: 0however much a guest trims. The page-cache lab trimmed 1.1 GiB and saw 0 (run 36815822140).Upstream fixed it in 331ce936c133 ("hw/virtio-blk: Account discard operations", Hanna Czenczek, reviewed by mst and Stefan Hajnoczi). It was merged to master on 2026-09-11 and is in no tag yet, v11.1.2 included.
qemu/patches/0002-…is that commit unchanged, plus a note below---saying why it is carried and when to drop it. The note says to delete it in the bump that brings it in; it would no longer apply (--forward).--fuzz=0to v11.1.1'shw/block/virtio-blk.c.boot/pagecache_test.go: the discard note now fails when the guest's fstrim leaves QEMU with 0 unmap operations.This is a new QEMU binary, so it changes the machine fingerprint. The release cycle decides when it ships.
Validation: the QEMU workflow builds this branch, then
boot:page-cacheruns on construct withqemu_runset to that build andvariant=instead.🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.