Snapshots nach createtxg statt creation sortieren #34

Closed

thorsten.spille wants to merge 0 commits from thorsten.spille/fix-30-sort-createtxg into main AGit

pull from: thorsten.spille/fix-30-sort-createtxg

merge into: bashclub:main

bashclub:main

bashclub:feature/12-systemd-timer

bashclub:feature/11-unprivileged

bashclub:feature/8-resume

bashclub:feature/7-skip-deleted-snapshots

bashclub:feature/6-holds

bashclub:feature/22-bookmarks

bashclub:fix/30-sort-createtxg

bashclub:fix/ci-checkzfs-fallback

bashclub:feature/25-integration-job

bashclub:feature/25-integration-tests

bashclub:feature/26-local-mode

bashclub:feature/9-bandwidth-limit

bashclub:feature/5-target-rollback

bashclub:feature/21-dataset-states

bashclub:feature/4-refquota

bashclub:feature/15-checkmk-monitoring

bashclub:fix/3-label-match

bashclub:fix/2-lock-per-config

bashclub:refactor/cleanup

bashclub:ci/forgejo

Conversation 1 Commits - Files changed -

thorsten.spille commented 2026-10-15 22:07:59 +02:00

Owner

Copy link

Setzt #30 um (freigegeben).

Problem

creation hat Sekundenauflösung. Snapshots eines Datasets aus derselben Sekunde (nur mit verschiedenen Namen möglich, z. B. zwei Labels) liefert ZFS bei -s creation und -S creation in derselben Reihenfolge. zfs list -S creation … | tail -1 ergab dann den neuesten dieser Snapshots als ältesten: die Erstreplikation begann dort, das Löschen nutzte den falschen ältesten Snapshot.

Änderung

Sortierschlüssel createtxg statt creation an allen 13 Stellen (12 in bashclub-zsync, 1 in remote-snapshot-manager).

• createtxg steigt pro Pool streng an und ordnet wie creation, nur ohne Gleichstand
• jede Liste wird auf ihrem eigenen Pool sortiert, verglichen wird per guid; auf dem Ziel entspricht die Reihenfolge dem Empfang (bei zsync chronologisch)
• wo Zeiten verglichen werden (Ursache einer gerissenen Kette), bleiben die Werte creation

Tests

• neuer Integrationsfall same_second (daily und weekly in derselben Sekunde): scheitert mit creation (Erstreplikation nur weekly-01), besteht mit createtxg
• ZFS-Integrationstests 11/11, Stub-Szenarien 23/23 mit identischen verändernden Aufrufen und Logs, Check-Tests 40/40

Closes #30

🤖 Generated with Claude Code

Setzt #30 um (freigegeben). ## Problem `creation` hat Sekundenauflösung. Snapshots eines Datasets aus derselben Sekunde (nur mit verschiedenen Namen möglich, z. B. zwei Labels) liefert ZFS bei `-s creation` und `-S creation` in derselben Reihenfolge. `zfs list -S creation … | tail -1` ergab dann den **neuesten** dieser Snapshots als ältesten: die Erstreplikation begann dort, das Löschen nutzte den falschen ältesten Snapshot. ## Änderung Sortierschlüssel `createtxg` statt `creation` an allen 13 Stellen (12 in bashclub-zsync, 1 in remote-snapshot-manager). - `createtxg` steigt pro Pool streng an und ordnet wie `creation`, nur ohne Gleichstand - jede Liste wird auf ihrem eigenen Pool sortiert, verglichen wird per guid; auf dem Ziel entspricht die Reihenfolge dem Empfang (bei zsync chronologisch) - wo Zeiten verglichen werden (Ursache einer gerissenen Kette), bleiben die Werte `creation` ## Tests - neuer Integrationsfall `same_second` (daily und weekly in derselben Sekunde): **scheitert mit `creation`** (Erstreplikation nur `weekly-01`), besteht mit `createtxg` - ZFS-Integrationstests 11/11, Stub-Szenarien 23/23 mit identischen verändernden Aufrufen und Logs, Check-Tests 40/40 Closes #30 🤖 Generated with [Claude Code](https://claude.com/claude-code)

thorsten.spille added 1 commit 2026-10-15 22:07:59 +02:00

Order snapshots by createtxg instead of creation ... c9b52bdd01

creation has a resolution of one second. For snapshots of a dataset created in
the same second (only possible with different names, e.g. two labels), ZFS
lists them in the same order with -s and -S creation. "zfs list -S creation |
tail -1" then returned the newest of them as the oldest: the initial
replication started there and the deletion used the wrong oldest snapshot.

createtxg increases strictly per pool and orders like creation without ties.
Every list is sorted on its own pool and compared by guid, on the target the
order of receiving is chronological. Where times are compared (cause of a
broken chain) the values stay creation. Also in remote-snapshot-manager.

Tests: integration case same_second (daily and weekly in the same second)
fails with creation and passes with createtxg; all stub scenarios identical.

Closes #30

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

thorsten.spille commented 2026-10-15 22:11:32 +02:00

Author

Owner

Copy link

Manuell nach main gemergt (8bffcb6), CI inkl. publish nach testing grün. Schließe den PR.

Manuell nach `main` gemergt (8bffcb6), CI inkl. publish nach testing grün. Schließe den PR.

thorsten.spille closed this pull request 2026-10-15 22:11:32 +02:00

All checks were successful

Hide checks

/ build (pull_request) Successful in 26s

Details

/ integration (pull_request) Successful in 56s

Details

/ test (debian-13) (pull_request) Successful in 43s

Details

/ test (ubuntu-24.04) (pull_request) Successful in 46s

Details

/ test (debian-12) (pull_request) Successful in 52s

Details

/ test (ubuntu-26.04) (pull_request) Successful in 52s

Details

/ publish (pull_request) Has been skipped

Details

/ package (pull_request) Successful in 0s

Details

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

bug

  

enhancement

No labels

bug

enhancement

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

bashclub/zsync!34

No description provided.