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 BA39B1FF14F for ; Tue, 28 Apr 2026 03:47:16 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 22A9E1DB8; Tue, 28 Apr 2026 03:47:16 +0200 (CEST) From: Thomas Lamprecht To: pbs-devel@lists.proxmox.com Subject: applied: [PATCH 0/2]: client: pxar: make payload-offset handling more robust Date: Tue, 28 Apr 2026 03:28:08 +0200 Message-ID: <20260428014635.2655155-1-t.lamprecht@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1777340705200 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.003 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [create.rs,proxmox.com] Message-ID-Hash: SBQUYDKKN7DO6B2VSUU2SXYDODCRIDZV X-Message-ID-Hash: SBQUYDKKN7DO6B2VSUU2SXYDODCRIDZV X-MailFrom: t.lamprecht@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: The strict payload-offset check added in pxar 1.0.1 rejects any PXAR_PAYLOAD_REF whose offset is not strictly greater than the encoder's previously recorded one. A producer-side bug in pre-1.0.1 clients let archives be written that violate that invariant: when a cache-range discontinuity opens between two flushes and the previous flush held its last chunk back for continuation, dedup against the next range's first chunk could collapse the held chunk away without ever injecting its bytes. payload_write_position then trails the previous_payload_offset recorded in the same flush, and the next add_payload_ref produces a backwards offset. With such an archive on disk, every later metadata-mode incremental backup aborts on the strict check until the chain is cycled out via --change-detection-mode=data. Patch 1 fixes the producer site: a held chunk is now injected explicitly when a cache-range discontinuity is detected, before update_range, so no held chunk can survive across a hole. Patch 2 lets existing affected archives "self-heal" on next backup: the Archiver tracks the highest previously-recorded payload offset globally and treats prev-archive entries with a smaller-or-equal offset as non-reusable, so they are re-encoded. A per-file warning makes the fall-back visible. Tracking is intentionally global so inversions that span cache ranges are caught too. Healthy archives written on or after pxar 1.0.1 cannot trigger the fall-back since the encoder already enforces strict monotonicity. tldr: avoids creating new backups that break our invariant and tries best to recover setups (new) backups, which should address some reports in the forum [0]. [0]: https://forum.proxmox.com/threads/183043/ Thomas Lamprecht (2): client: pxar: inject held chunk on cache-range discontinuity client: pxar: re-encode files with non-monotonic previous offsets pbs-client/src/pxar/create.rs | 123 ++++++++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) -- 2.47.3