From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Fiona Ebner <f.ebner@proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server] fix #6207: vm status: cache last disk read/write values
Date: Mon, 22 Sep 2025 19:26:12 +0200 [thread overview]
Message-ID: <cb87769c-83dc-481a-a1ea-33add5087008@proxmox.com> (raw)
In-Reply-To: <20250922101749.34397-1-f.ebner@proxmox.com>
Am 22.09.25 um 12:18 schrieb Fiona Ebner:
> If disk read/write cannot be queried because of QMP timeout, they
> should not be reported as 0, but the last value should be re-used.
> Otherwise, the difference between that reported 0 and the next value,
> when the stats are queried successfully, will show up as a huge spike
> in the RRD graphs.
Fine with the idea in general, but this is effectively relevant for
the pvestatd only though?
As of now we would also cache in the API daemon, without every using
this. Might not be _that_ much, so not really a problem of the amount,
but feels a bit wrong to me w.r.t. "code place".
Has pvestatd the necessary info, directly on indirectly through the
existence of some other vmstatus properties, to derive when it can
safely reuse the previous value?
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)?
_______________________________________________
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-22 17:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-22 10:15 Fiona Ebner
2025-09-22 17:26 ` Thomas Lamprecht [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=cb87769c-83dc-481a-a1ea-33add5087008@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=f.ebner@proxmox.com \
--cc=pve-devel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox