On Mon, May 11, 2026 at 22:46:01 +0200, Denis V. Lunev wrote: > On 5/11/26 22:37, Peter Krempa wrote: > > On Mon, May 11, 2026 at 22:21:35 +0200, Denis V. Lunev wrote: > >> qemuDomainBlockResize() issues block_resize via QMP, which updates the > >> qcow2 header on disk and bs->total_sectors in qemu, but the cached > >> disk->src->capacity in libvirt is left at its pre-resize value. > >> > >> All current readers re-read capacity from either QMP or the file itself > >> before returning to the user, so the staleness is not externally > >> observable today. Still, the cached field should reflect what we just > >> asked qemu to write; keeping the two in sync avoids surprises for any > >> future consumer that trusts the cached value. > > None of those values are stored in the status XML so they will be > > missing in certain situations. Each caller who wants to read the > > 'capacity', 'allocation' or 'physical' field *must* update it before any > > read. > > > > The commit message doesn't IMO provide enough justification to do this > > since each caller will update it. > > > we have faced problem in downstream with a surprise that this value > is stale but that could be not a very good reason to make this in.
No. Well unless the "downstream" code you have will be upstreamed. But then still it's not a good idea to in any way rely on that value, so really no. > Would it worth to make a comment in the header instead that this > value is unreliable and should be re-read? Yes, you can add a comment to the virStorageSource struct stating that unless updated the values don't represent reality. In addition you can state that 'allocation' is ultra-unreliable because any guest write to a previously unallocated part of the sparse image invalidates that value even if the value is not 0/seems updated.
