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 <sage@inktank.com>

diff --git a/src/os/JournalingObjectStore.cc b/src/os/JournalingObjectStore.cc
index 402fa3cc9757a54d1152e61a8198819ea3280e88..cdf16ddbd7de368686d5f754f47b42224d44300d 100644 (file)
--- 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 946ab7cefc79603e1652ed283e35bc1073c12e5c..fb7f0eca6d78bb85d3d4c69b1bb7b28d68f59665 100644 (file)
--- 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);