Bug #13089
closedmon: check for store writeablility before participating in election
0%
Updated by Greg Farnum over 8 years ago
Mmm, I'm not sure we want to do the naive thing (write a file and fsync) on every election as that will slow them down a lot in the common case. Probably if we just check store accessibility on bootup, flip a flag if we ever fail one, and check for it on every election?
Updated by Sage Weil over 8 years ago
Greg Farnum wrote:
Mmm, I'm not sure we want to do the naive thing (write a file and fsync) on every election as that will slow them down a lot in the common case. Probably if we just check store accessibility on bootup, flip a flag if we ever fail one, and check for it on every election?
Yeah I think a check on boot is sufficient.
Updated by Joao Eduardo Luis over 8 years ago
Can we have a bit more context please? What's the rationale behind this? The monitor should not start if leveldb is not open, and since it's not open it's not writeable. Is this in case the disk is full or the fs is read-only? Or something else I'm missing?
Updated by Kefu Chai over 8 years ago
- Status changed from New to Fix Under Review
- Assignee changed from Kefu Chai to Sage Weil
Updated by Kefu Chai over 8 years ago
- Tags deleted (
hammer) - Backport set to hammer
Updated by Sage Weil over 8 years ago
- Status changed from Fix Under Review to Pending Backport
Updated by Loïc Dachary over 8 years ago
- Backport changed from hammer to hammer,firefly
Updated by Loïc Dachary over 8 years ago
- Status changed from Pending Backport to Resolved
Updated by Kefu Chai about 8 years ago
please note that the background compaction fails, if leveldb can not create new tables or remove merged tables.
so, if we "chmod -w store.db". and leveldb complains in this case, but it does not return error on Write() unless "leveldb_paranoid" is true, but this option is "false" by default. so "failed to write to db" assertion is not triggered, even if compaction fails with the default settings.