[SDSTOR-23023] Add option to commit_blk for post-crash resync#896
Conversation
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## stable/v7.x #896 +/- ##
==============================================
Coverage ? 48.18%
==============================================
Files ? 110
Lines ? 12964
Branches ? 6229
==============================================
Hits ? 6247
Misses ? 2581
Partials ? 4136 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
xiaoxichen
left a comment
There was a problem hiding this comment.
the force_cache is a bit wired, maybe force is enough or pick a better name (the cache expose internal implementation and wired to api user)
|
other part LGTM |
Normally commit_blk is called either during recovery (which advances both watermarks) or after a fresh alloc. However, in some scenarios, a blk_id may be recorded to be live by the caller but the allocator watermarks have not been successfully persisted. The new `recommit` parameter allows the caller to unconditionally advance both m_last_append_offset and m_commit_offset, covering such cases without requiring the system to be in initialising mode. Signed-off-by: Kou, Jilong <jkou@ebay.com>
Good idea, changed to |
https://jirap.corp.ebay.com/browse/SDSTOR-23023
Normally commit_blk is called either during recovery (which advances both watermarks) or after a fresh alloc. However, in some scenarios, a blk_id may be recorded to be live by the caller but the allocator watermarks have not been successfully persisted.
The new
force_cacheparameter allows the caller to unconditionally advance both m_last_append_offset and m_commit_offset, covering such cases without requiring the system to be in initialising mode.Related PR: eBay/HomeObject#452