From: Fiona Ebner <f.ebner@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: [pve-devel] superseded: [PATCH qemu-server] fix #6207: vm status: cache last disk read/write values
Date: Thu, 25 Sep 2025 14:31:28 +0200 [thread overview]
Message-ID: <b7f18cfc-2927-4e19-adf7-190001ae7240@proxmox.com> (raw)
In-Reply-To: <841c9758-1478-431f-8cd4-e8fd8c0ac9cd@proxmox.com>
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/
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2025-09-25 12:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-22 10:15 [pve-devel] " Fiona Ebner
2025-09-22 17:26 ` Thomas Lamprecht
2025-09-25 8:27 ` Fiona Ebner
2025-09-25 8:52 ` Thomas Lamprecht
2025-09-25 9:28 ` Fiona Ebner
2025-09-25 12:31 ` Fiona Ebner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b7f18cfc-2927-4e19-adf7-190001ae7240@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.