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>
(cherry picked from commit 4de49e8676748b6ab4716ff24fd0a465548594fc)

diff --git a/src/os/JournalingObjectStore.cc b/src/os/JournalingObjectStore.cc
index e662580ac42bf3270a6c19d1cd50fab6bcbadade..932dd344f36cdb76f61d6b92b14195856f136caa 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 338ac87ec21622d94b78176b5635b2d6246483e5..9135da42fc0dd4b5c18d0a0bb30d7855e642c44c 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);