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))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id CFF5990213
for <pbs-devel@lists.proxmox.com>; Wed, 5 Oct 2022 17:57:08 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 9F55E419D
for <pbs-devel@lists.proxmox.com>; Wed, 5 Oct 2022 17:56:38 +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, 5 Oct 2022 17:56:37 +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 0F3B8444EF
for <pbs-devel@lists.proxmox.com>; Wed, 5 Oct 2022 17:56:37 +0200 (CEST)
Message-ID: <d51beb39-90ee-9509-5cfb-63b137b1c7f3@proxmox.com>
Date: Wed, 5 Oct 2022 17:56:36 +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: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com>,
Daniel Tschlatscher <d.tschlatscher@proxmox.com>
References: <20220824102657.159735-1-d.tschlatscher@proxmox.com>
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <20220824102657.159735-1-d.tschlatscher@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 1.194 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.449 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
URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
information. [proxmox-backup-proxy.rs, status.rs, status.total, disk.dev]
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, 05 Oct 2022 15:57:08 -0000
Am 24/08/2022 um 12:26 schrieb Daniel Tschlatscher:
> The rrd data now includes tracking the total disk usage for the unpri-
> vileged backup user. The calculation for the estimated_time_full was
> adapted to use the total for the unpriviliged user.
>
> The unpriv_total is the sum of the used space in the file system, plus
> the available space for the unpriviliged user.
>
> Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
> Reviewed-by: Matthias Heiserer <m.heiserer@proxmox.com>
> ---
> No changes from v3
>
> src/api2/status.rs | 3 ++-
> src/bin/proxmox-backup-proxy.rs | 2 ++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/api2/status.rs b/src/api2/status.rs
> index 50d401c2..b918156e 100644
> --- a/src/api2/status.rs
> +++ b/src/api2/status.rs
> @@ -84,7 +84,8 @@ pub async fn datastore_status(
> let get_rrd =
> |what: &str| extract_rrd_data(&rrd_dir, what, RRDTimeFrame::Month, RRDMode::Average);
>
> - let total_res = get_rrd("total")?;
> + // Use the space for the unpriviliged user, as e.g. ext4 reserves 5% of disks for root only
> + let total_res = get_rrd("unpriv_total")?;
But we only just started to even record that, so it's not _that_ ideal to directly switch
as the user will notice a possible big jump after the upgrade. Can we check how many data is
in there to decide which one to use, or do it more heuristically and start recording now but
switch only in a later usage (e.g., the point release after the next one).
> let used_res = get_rrd("used")?;
>
> if let (
> diff --git a/src/bin/proxmox-backup-proxy.rs b/src/bin/proxmox-backup-proxy.rs
> index 214bc9b1..e5c8813f 100644
> --- a/src/bin/proxmox-backup-proxy.rs
> +++ b/src/bin/proxmox-backup-proxy.rs
> @@ -1273,6 +1273,8 @@ fn rrd_update_disk_stat(disk: &DiskStat, rrd_prefix: &str) {
> rrd_update_gauge(&rrd_key, status.total as f64);
> let rrd_key = format!("{}/used", rrd_prefix);
> rrd_update_gauge(&rrd_key, status.used as f64);
> + let rrd_key = format!("{}/unpriv_total", rrd_prefix);
> + rrd_update_gauge(&rrd_key, (status.used + status.available) as f64);
what speaks against broadcasting available? I mean one got the same information
either way, but mirroring the disk stats and returning total, used, available instead
of "two" totals sounds somewhat nicer to be from an API-User POV, but no hard feelings
here, just stuck quite a bit out to me after reviewing this series finally.
> }
>
> if let Some(stat) = &disk.dev {