On Sat, Nov 15, 2025 at 10:24:34AM +0300, Michael Tokarev wrote: > On 11/15/25 03:38, Andrea Bolognani wrote: > > On Sat, Nov 15, 2025 at 01:40:51AM +0300, Michael Tokarev wrote: > > > > > > https://gitlab.com/qemu-project/qemu/-/commit/6f3199f99600fe75f32f78574e507f347de80854 > > > > > > (and a subsequent test for this as well). > > > > > > It would be nice to have an easier reproducer still, to verify > > > this. Maybe the test would do. > > > > Yeah that looks like a very plausible candidate. I can build the > > trixie package with that commit on top and check whether it's enough > > to make the issue go away. I'll report back within a few days. > > There are 4 commits which should be picked up, - the mentioned > one and 3 before it, which does some preparations. And the > next one is the test for the CI which verifies the prob is > not here anymore. > > See https://gitlab.com/mjt0k/qemu/-/commits/staging-10.0 -- > these are commits queued up for the next 10.0.x stable > release. Current 5 commits on top (up to 13607c37c0118a95b > which is the test) are the ones I'm talking about.
Still haven't gotten around to this, sorry. I'll try to sort it out soon, but in the meantime I'm left wondering... Seeing how things work as expected with detect_zeroes=unmap, is it really unexpected that setting detect_zeroes=off will throw sparseness out of the window? Or are those commits solving the issue where QEMU knows (ret & BDRV_BLOCK_ZERO) that it is supposed to generate sparseness (blk_co_pwrite_zeroes) but fails to actually do so? I'm not really familiar with QEMU's code, so any help understanding what's going on would be much appreciated. -- Andrea Bolognani <[email protected]> Resistance is futile, you will be garbage collected.
signature.asc
Description: PGP signature
