From 4de49e8676748b6ab4716ff24fd0a465548594fc Mon Sep 17 00:00:00 2001 From: Sage Weil Date: Tue, 8 Apr 2014 10:52:43 -0700 Subject: [PATCH] os/FileStore: reset journal state on umount We observed a sequence like: - replay journal - sets JournalingObjectStore applied_op_seq - umount - mount - initiate commit with prevous applied_op_seq - replay journal - commit finishes - on replay commit, we fail assert op > committed_seq Although strictly speaking the assert failure is harmless here, in general we should not let state leak through from a previous mount into this mount or else assertions are in general more difficult to reason about. Fixes: #8019 Signed-off-by: Sage Weil --- src/os/JournalingObjectStore.cc | 1 + src/os/JournalingObjectStore.h | 7 +++++++ 2 files changed, 8 insertions(+) diff --git a/src/os/JournalingObjectStore.cc b/src/os/JournalingObjectStore.cc index 402fa3cc9757a..cdf16ddbd7de3 100644 --- a/src/os/JournalingObjectStore.cc +++ b/src/os/JournalingObjectStore.cc @@ -25,6 +25,7 @@ void JournalingObjectStore::journal_stop() delete journal; journal = 0; } + apply_manager.reset(); } int JournalingObjectStore::journal_replay(uint64_t fs_op_seq) diff --git a/src/os/JournalingObjectStore.h b/src/os/JournalingObjectStore.h index 946ab7cefc796..fb7f0eca6d78b 100644 --- a/src/os/JournalingObjectStore.h +++ b/src/os/JournalingObjectStore.h @@ -68,6 +68,13 @@ protected: max_applied_seq(0), com_lock("JOS::ApplyManager::com_lock", false, true, false, g_ceph_context), committing_seq(0), committed_seq(0) {} + void reset() { + assert(open_ops == 0); + assert(blocked == false); + max_applied_seq = 0; + committing_seq = 0; + committed_seq = 0; + } void add_waiter(uint64_t, Context*); uint64_t op_apply_start(uint64_t op); void op_apply_finish(uint64_t op); -- 2.39.5