Skip to content

S3: read+commit - follow up - #178

Closed
shosseinimotlagh wants to merge 1 commit into
eBay:dev/v6.xfrom
shosseinimotlagh:S3_read_commit_followup
Closed

S3: read+commit - follow up#178
shosseinimotlagh wants to merge 1 commit into
eBay:dev/v6.xfrom
shosseinimotlagh:S3_read_commit_followup

Conversation

@shosseinimotlagh

Copy link
Copy Markdown
Contributor

Summary

Follow-up to #175 (S3: Commit + Read path, SDSTOR-22733). Two of the items found by an independent post-merge review pass are fixed here; the rest are tracked as design-decision items under a new story, SDSTOR-25614, rather than blocking on them here.

Fixed in this PR

# Description Fix
1 free_slot() was missing the magic/version/hdr.lsn==lsn/hdr.len validation that read_slot() already has right next to it — a corrupt on-disk record could deserialize a garbage blkid and free the wrong blocks. Added the same validate-before-trust guards read_slot() uses.
2 write()'s post-flight block erased dlsn from missing_lsns_ and released missing_mu_ before calling populate_overlay(). A concurrent commit_impl run (another write()'s or keep_alive()'s piggyback) could see dlsn already resolved, apply + retire it, and advance commit_lsn past it — all before this call got around to inserting the overlay entry. Net effect: a permanently-orphaned (harmless, but never-retired) overlay entry until the same LBA is next overwritten. Both mutations now happen under the same missing_mu_ critical section that commit_impl's is_missing check also takes — commit_impl either still sees dlsn as missing (stalls) or sees it resolved with the overlay already populated; the in-between state no longer exists.

Tracked, not fixed here (needs a design decision)

Filed under SDSTOR-25614 ("CRAFT S3 follow-up: overlay versioning, read/commit atomicity, and corrupt-record failure handling"), carried over from #175's review:

  • SDSTOR-25615 — journal-tail overlay's single-version-per-LBA limitation (loses a superseded-but-still-valid write on a horizon-clamped read).
  • SDSTOR-25616read_impl/commit_impl non-atomicity: a read's index-check and overlay-check can straddle a concurrent commit, returning stale data with a fresh watermark.
  • SDSTOR-25617 — asymmetric corrupt-record failure handling: a bad journal record latches the partition forever at restart, but only fails one call at a time (retried forever) at runtime.
  • SDSTOR-25619 — new: commit_impl's is_empty snapshot is stale-able by a concurrent apply_sync_rs_commit_lsn run, letting Empty-verdicted data get applied to the index.

Out of scope (separate ticket, different story's code)

SDSTOR-25620apply_sync_rs_commit_lsn (S5, PR #176) advances commit_lsn for peer-fetched/resolved slots without ever applying them to the index or overlay, so a lagging replica's catch-up path can leave commit_lsn ahead of what's actually servable — subsequent reads of those LBAs return holes. Confirmed via diff that this PR (and #175) never touched that function's logic. Filed as a standalone bug against S5/S6, not a subtask of the S3 follow-up story.

Testing

Built and ran the full suite on sdsbuild06 (Debug, C++23): both craft_client (13/13) and homeblocks (13/13) test binaries pass, including all CRAFT suites — no regressions from these two fixes.

…ay race

Independent post-eBay#175 review findings (build-verified, 26/26 test suites pass):

- free_slot() was missing the same magic/version/hdr.lsn==lsn/hdr.len
  validation read_slot() already has -- a corrupt record could deserialize
  a garbage blkid and free the wrong blocks.
- write()'s post-flight block erased dlsn from missing_lsns_ and released
  missing_mu_ before calling populate_overlay(), letting a concurrent
  commit_impl (another write's/keep_alive's piggyback) apply and retire
  dlsn before the overlay entry existed -- leaving a permanently-orphaned
  (harmless but never-retired) overlay entry. Both mutations now happen
  under the same missing_mu_ critical section commit_impl's is_missing
  check also takes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant