[pve-devel] superseded: [PATCH qemu-server] fix #6207: vm status: cache last disk read/write values

[Fiona Ebner]

Am 25.09.25 um 11:28 AM schrieb Fiona Ebner:
> Am 25.09.25 um 10:52 AM schrieb Thomas Lamprecht:
>> Am 25.09.25 um 10:27 schrieb Fiona Ebner:
>>> Am 22.09.25 um 7:26 PM schrieb Thomas Lamprecht:
>>>> Am 22.09.25 um 12:18 schrieb Fiona Ebner:
>>>> Or maybe we could make this caching opt-in through some module flag
>>>> that only pvestatd sets? But not really thought that through, so
>>>> please take this with a grain of salt.
>>>>
>>>> btw. what about QMP being "stuck" for a prolonged time, should we
>>>> stop using the previous value after a few times (or duration)? 
>>>
>>> What other value could we use? Since the graph looks at the differences
>>> of reported values, the only reasonable value we can use if we cannot
>>> get a new one is the previous one. No matter how long it takes to get a
>>> new one, or there will be that completely wrong spike again. Or is there
>>> a N/A kind of value that we could use, where RRD/graph would be smart
>>> enough to know "I cannot calculate a difference now, will have to wait
>>> for multiple good values"? Then I'd go for that instead of the current
>>> approach.
>>
>> That should never be the problem of the metric collecting entity, but of
>> the one interpreting or displaying the data, as else this is creating a
>> false impression of reality.
>>
>> So the more I think of this, the more I'm sure that we won't do anybody
>> a favor in the mid/long term here with "faking it" in the backend.
> 
> Very good point! I'll look into what happens when reporting an undef
> value, because right now the interpreting entity cannot distinguish
> between "0 because of no data" and "0 yes I really mean this is the
> actual value".

Returning undef already works as intended :)

Superseded by:
https://lore.proxmox.com/pve-devel/20250925122829.70121-1-f.ebner@proxmox.com/T/