Skip to content

Concurrent write during same-volume compaction can dangle an in-flight put (OP8) #2

Description

@badnikhil

Category: known limitation, outside the v1 single-writer model. DESIGN.md Section 18 open problem 8.

Context

The v1 concurrency model is a single logical writer, CAS-serialized (DESIGN Section 13.1).

What IS protected (M5 defense-in-depth)

Engine::commit_compaction rebuilds its repoint set from the current namespace on every CAS attempt and aborts if a racing writer committed data to the retiring volume that this pass did not rewrite. So committed files are never lost to a concurrent compaction.

What is NOT protected

An in-flight write: a put whose Phase-1 segment has been pushed to volume V but whose Phase-2 CAS has not yet landed, while a compaction retires and destroys V. The put's eventual commit then references a destroyed segment (dangling ref → later read fails).

Demonstrating test (the acceptance criterion)

tests/compaction.rs::issue_2_inflight_put_survives_concurrent_compaction#[ignore]d. Uses a new GITSTORAGE_PAUSE hook to hold a put between its Phase-1 push and Phase-2 commit while a compaction destroys its volume; asserts the committed put is still readable. It fails today with chunk ... missing from segment — the put commits successfully but its data is gone. Run with cargo test --test compaction -- --ignored issue_2.

Possible fix

Phase-1 re-validation on rebase (re-push/verify the segment before committing), or exclude recently-written volumes from compaction. Belongs with the optimistic-writer work (#… / DESIGN Section 13.4).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions