From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 3CE881FF165 for ; Thu, 25 Sep 2025 14:31:02 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 609A320639; Thu, 25 Sep 2025 14:31:32 +0200 (CEST) Message-ID: Date: Thu, 25 Sep 2025 14:31:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Fiona Ebner To: Thomas Lamprecht , Proxmox VE development discussion References: <20250922101749.34397-1-f.ebner@proxmox.com> <9facf42e-748f-4427-ab8d-eb133d55425b@proxmox.com> <0681c879-433c-49d6-ae56-582111efb5ee@proxmox.com> <841c9758-1478-431f-8cd4-e8fd8c0ac9cd@proxmox.com> Content-Language: en-US In-Reply-To: <841c9758-1478-431f-8cd4-e8fd8c0ac9cd@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1758803474370 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.022 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pve-devel] superseded: [PATCH qemu-server] fix #6207: vm status: cache last disk read/write values X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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