Skip to content

borg2: clock skew issues #9870

Description

@ThomasWaldmann

Locking

Staleness compares the lock's timestamp (writer's clock) against the reader's local clock (storelocking.py:127). With skew > 30 min, client B kills client A's healthy lock and can run compact. A's Lock.refresh only checks its lock still exists once refresh_td (15 min) has passed since its last refresh, so A can keep dedup-referencing chunks for up to ~15 minutes while compact deletes them — a finished archive referencing deleted chunks. The suspend/resume case is handled (a >30 min suspend guarantees the very next refresh acts and aborts); pure clock skew is not. Worth at least a docs warning ("shared repos require synchronized clocks"), or a cheap sanity check comparing other locks' timestamps against local now.

Manifest timestamp

The manifest replay detector: two concurrent manifest.write()s with skewed clocks can commit a final timestamp lower than what the other client cached, so that client's next run raises RepositoryReplay (security.py:162). Manifest.write's monotonic bump only protects sequential writers.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions