From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 796711FF15E for ; Fri, 18 Oct 2024 10:32:50 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8823C1D905; Fri, 18 Oct 2024 10:33:24 +0200 (CEST) Message-ID: Date: Fri, 18 Oct 2024 10:33:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox Backup Server development discussion References: <20241011093355.218198-1-c.ebner@proxmox.com> <20241011093355.218198-2-c.ebner@proxmox.com> <3d6ae324-7aab-4547-87f4-b63f632c0b3e@proxmox.com> <537595b3-00bc-4663-907f-1ea1e7a10927@proxmox.com> <918a092b-703c-485d-9ca1-c48a9c3339b4@proxmox.com> <65709388-789e-4531-acfa-38eefed6be78@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.027 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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] applied: [PATCH v3 proxmox-backup] partial fix #5560: client: periodically show backup progress X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On 10/18/24 09:53, Thomas Lamprecht wrote: > Am 18/10/2024 um 09:37 schrieb Christian Ebner: >> One thing still came to mind yesterday though: >> Progress logging is now enabled unconditionally, and as is it is not >> possible to disable it or configure the interval. >> >> So I plan to send a patch to make the progress log output opt-in, and > > Personally I'd prefer opt-out, I'm not a fan of tools that stay silent > by default (looking at you `dd`). > > Tools can always turn this off easily, and we already have some output > so it's not like we'd previously have none and now suddenly print stuff, > which might indeed surprise some existing users that relied on no output > (IMO a bit weird thing to do, but well not completely out of the picture) Ack'ed, so let's keep the current default progress log output interval of 60 seconds and make it opt-out by allowing to set the interval to 0. Disabling should however be possible, as the backup upload writer stream might be used in other places as well, having unintentional side effects (e.g. the sync job in push direction will use the same code path). > >> make the interval configurable within a meaningful value range (maybe >> within 0s to 3600s?). >> >> Something like: >> ``` >> proxmox-backup-client backup root.pxar:/ --progress-log-interval=10 >> ``` >> >> And disable progress log output for a value of 0 or the optional >> parameter is not given. >> >> That would also allow to more flexibly control the behavior when being >> invoked by vzdump. >> >> What are your opinions on that? > > Minus the s/opt-in/opt-out/ preference that's fine by me. We could then > also switch to a higher reporting rate in PVE, albeit FWIW, for VM backups > there we use 10s and then slow down after some time, trying to take a > balance for early fast feedback and short backups and long backups. > And just throwing out ideas, one could also do a size-related interval, > like print a report every (at least) X MB or GB uploaded. Hmm, that would be nice to have, maybe allow to pass either a `TimeSpan` or a `HumanByte` for the log interval parameter? Not sure if parsing would work without possible value clashes though (e.g. 4M could be 4 months or 4 MiB...). But maybe that is overkill and not so user friendly, the better option being to set either time or size based intervals by (yet another) flag. > Oh, and do you plan to take a TimeSpan as interval parameter? Might > provide nice UX here. That is a great idea! _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel