-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
always truncate when SyncWrites is enabled #30
Conversation
This will delete values that were in the process of being "put" when we crashed but that's likely expected behavior anyways. Without this, ipfs on badger may refuse to start after a crash.
8ec16fa
to
d5c834c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're assuming here (and it seems reasonable) that SyncWrites
wasn't modified after the crash.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been running few nodes with similar patch for quite some time now, it even survived few crashes
An alternative is to have a |
Yes, I agree, that was the intention behind ipfs/kubo#5275.
I would prefer to set it to false by default, just to be conservative here, and document the possibility that a truncate might be needed after a crash and how the user can set it to true, but I don't really feel that strong about it, true is also ok. |
Given the semantics of our datastore, I'd prefer to set it to true (and document it). I'm pretty sure all (or almost all) filesystems/databases behave this way. Basically:
Are there any cases I'm missing? |
If |
This will delete values that were in the process of being "put" when we crashed
but that's likely expected behavior anyways. Without this, ipfs on badger may
refuse to start after a crash.
part of ipfs/kubo#5275