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 0CEC81FF132 for ; Mon, 27 Apr 2026 12:08:00 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D4809176FA; Mon, 27 Apr 2026 12:07:59 +0200 (CEST) Date: Mon, 27 Apr 2026 12:07:22 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= Subject: Re: [PATCH proxmox-backup] api/tools: avoid showing error on missing manifest during file listing To: Christian Ebner , pbs-devel@lists.proxmox.com References: <20260426080346.159579-1-c.ebner@proxmox.com> <1777281748.vnn3diw30o.astroid@yuna.none> <744e7fed-3787-4bf8-b550-0a2f5f9c5bb3@proxmox.com> In-Reply-To: <744e7fed-3787-4bf8-b550-0a2f5f9c5bb3@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.17.0 (https://github.com/astroidmail/astroid) Message-Id: <1777284321.3aaao1mwxx.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1777284350855 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.054 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 Message-ID-Hash: YRA5MPBDV2RGTTJTDE4XHA3FA3EWS5NL X-Message-ID-Hash: YRA5MPBDV2RGTTJTDE4XHA3FA3EWS5NL X-MailFrom: f.gruenbichler@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On April 27, 2026 11:51 am, Christian Ebner wrote: > On 4/27/26 11:22 AM, Fabian Gr=C3=BCnbichler wrote: >> On April 26, 2026 10:03 am, Christian Ebner wrote: >>> When listing the contents of a datastore, a missing manifest blob >>> file is currently being logged as error to the systemd journal [0]. >>> The manifest missing is however normal operation in case of a still >>> ongoing backup. Therefore, refactor the code such that a missing >>> manifest is not treated as regular error by returning an Option::None >>> in the read_backup_index() helper, and handle this case accordingly. >>> >>> The actual check for the missing manifest should further be improved, >>> but requires a more in depth refactoring, the changes here acting as >>> a stop gap for not showing the benign error the time being. >>=20 >> how about the following instead? only log the error if the manifest file >> has existed before we tried to load and parse it? that should limit the >> log spam to >> - actually broken manifests >> - manifests which disappear right between those two calls >>=20 >=20 > That has one major downside though: This is a highly critical code path,=20 > the content listing having already been reworked quite a bit int the=20 > past to not be slow. >=20 > So your suggested changes would now unconditionally add more syscalls=20 > and IO? true, I initially had the call in the Err path (which would mean not differentiating between "manifest does not exist in the first place" and "manifest disappeared under us", which is probably fine?) the additional single stat here should be cheap compared to parsing the full manifest, if we only do it in the Err(path).. > I think it would be better to refactor the code in the long run, so a=20 > missing manifest would be treated differently from parsing and other IO=20 > errors, and bubbled up to the call site for logging. but yeah, doing that is probably also fine, we just need to really do it ;)