From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id E6F7D9245E for <pbs-devel@lists.proxmox.com>; Wed, 12 Oct 2022 13:31:45 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CB70C252DC for <pbs-devel@lists.proxmox.com>; Wed, 12 Oct 2022 13:31:45 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pbs-devel@lists.proxmox.com>; Wed, 12 Oct 2022 13:31:45 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id DC7094493E for <pbs-devel@lists.proxmox.com>; Wed, 12 Oct 2022 13:31:44 +0200 (CEST) Message-ID: <34d7c201-12ee-df7f-b0be-db7d6bdd91db@proxmox.com> Date: Wed, 12 Oct 2022 13:31:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Thunderbird/106.0 Content-Language: en-GB To: Daniel Tschlatscher <d.tschlatscher@proxmox.com>, Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> References: <20220824102657.159735-1-d.tschlatscher@proxmox.com> <d51beb39-90ee-9509-5cfb-63b137b1c7f3@proxmox.com> <a0173737-787a-1fc9-9ec0-d859864bce76@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <a0173737-787a-1fc9-9ec0-d859864bce76@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.433 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -2.934 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup v4 1/3] fix #4077: Estimated Full metric on ext4 file systems X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion <pbs-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/> List-Post: <mailto:pbs-devel@lists.proxmox.com> List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Wed, 12 Oct 2022 11:31:45 -0000 Am 10/10/2022 um 16:23 schrieb Daniel Tschlatscher: > It seems to me, finding a way to tell which dataset to use for the > calculation is the preferable way here, as the heuristic approach of > recording it anyway and switching at a later date would show the same > jump for users upgrading from an earlier version or in cases where the > RRDB did not have enough time to populate between versions. sure, if you don't add a dynamic check on runtime, but the one that update are often those that update frequently or on every point release, so it probably would cover a major part of users - albeit, that's rather guesstimation and it's also a burden to keep track and communicate to users, so probably better to either mix in dynamically, if new value hasn't enough data but old value has, or just ignore it altogether; I'd at least try to do the former, if it's a lot of complexity we can still drop it. > Or would you reckon this is acceptable in such (less frequent) cases, as > it is more of a cosmetic feature anyway? certainly no deal breaker, not sure how much its actually used, or relied on in practice anyway. > Mostly, it made it easier to just drop in place instead of the value for > total, rather than querying combining the data for used and available. I > didn't overwrite it also, as that would be a breaking change. > > In my eyes, it is also more easily understandable from the POV of an API > user because the naming for available does not inherently carry the > information that this value excludes any unusable storage for > unprivileged users. > I see potential for confusion here, as one might incorrectly assume that > used + available = total, when that is, in my testing, really never the > case. Potentially, because of reserved blocks on ext4 file systems and > because of a small amount which seems to be claimed by the kernel. > not convinced. df or findmnt --df all show size (total), used and avail, and those tools a pretty much standard since decades. total_unpriv is really not _that_ telling if one comes from the outside, as it isn't clear what unrpiv refers to at all IMO and why there are two totals, if they should be sumed together (i.e., is total the one for priv + unrpiv or just priv)... I'd rather just stick to established defaults/terms and avoid inventing new ones.