public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
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	[thread overview]
Message-ID: <20260428014635.2655155-1-t.lamprecht@proxmox.com> (raw)

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





             reply	other threads:[~2026-04-28  1:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-28  1:28 Thomas Lamprecht [this message]
2026-04-28  1:28 ` [PATCH 1/2] client: pxar: inject held chunk on cache-range discontinuity Thomas Lamprecht
2026-04-28  1:28 ` [PATCH 2/2] client: pxar: re-encode files with non-monotonic previous offsets Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260428014635.2655155-1-t.lamprecht@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal