Skip to content
This repository was archived by the owner on Sep 5, 2025. It is now read-only.

Hold write lock during fs remove in gc#39

Closed
jgrund wants to merge 1 commit into
fjall-rs:mainfrom
whamcloud:jgrund/hold-lock
Closed

Hold write lock during fs remove in gc#39
jgrund wants to merge 1 commit into
fjall-rs:mainfrom
whamcloud:jgrund/hold-lock

Conversation

@jgrund
Copy link
Copy Markdown

@jgrund jgrund commented Jun 18, 2025

This change holds the segement write lock while we remove stale files from the fs. This resolves a race condition where reads can try to reference files that no longer exist on disk.

Fixes #38

Signed-off-by: Joe Grund <jgrund@whamcloud.io>
@jgrund jgrund changed the title Workaround race-condition in GC Hold write lock during fs remove in gc Jun 18, 2025
@marvin-j97
Copy link
Copy Markdown
Contributor

I don't think this actually solves the underlying issue, where you can hold a value handle, then the blob file gets rewritten, then you resolve the value handle.

Also the read lock is only held shortly, so it could still read the file while not being locked.

@marvin-j97
Copy link
Copy Markdown
Contributor

FWIW if the read lock was extended, it would probably solve the race condition here in value-log, but lsm-tree can probably still crash under certain circumstances (https://github.com/fjall-rs/lsm-tree/blob/main/src%2Fblob_tree%2Fmod.rs#L47). Basically you when you retrieve a value handle, you get locked out by GC and suddenly the blob file is gone.

@jgrund
Copy link
Copy Markdown
Author

jgrund commented Jul 2, 2025

Thanks, I wasn't sure if I got the whole solution or not.

@marvin-j97 marvin-j97 closed this Sep 1, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GC allows read of stale data

2 participants