FileJournal: clarify meaning of start_seq and fix initialization

Second guessing the first sequence number from the FileStore
was silly and broke tests which had the temerity to start at
1 instead of 2...

Fixes: #4687
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>

2 files changed, 17 insertions, 4 deletions

diff --git a/src/os/FileJournal.cc b/src/os/FileJournal.cc
index f5e8f34137e..29139c12bca 100644
--- a/src/os/FileJournal.cc
+++ b/src/os/FileJournal.cc
@@ -389,9 +389,7 @@ int FileJournal::create()
     header.alignment = 16;  // at least stay word aligned on 64bit machines...
 
   header.start = get_top();
-  /* FileStore::mkfs initializes the fs op sequence file at 1.  Therefore,
-   * the first entry written must be  at sequence 2.*/
-  header.start_seq = 2;
+  header.start_seq = 0;
 
   print_header();
 
diff --git a/src/os/FileJournal.h b/src/os/FileJournal.h
index 7b1777928cd..0e826fb4940 100644
--- a/src/os/FileJournal.h
+++ b/src/os/FileJournal.h
@@ -109,7 +109,22 @@ public:
     int64_t max_size;   // max size of journal ring buffer
     int64_t start;      // offset of first entry
     uint64_t committed_up_to; // committed up to
-    uint64_t start_seq;   // entry at header.start
+
+    /**
+     * start_seq
+     *
+     * entry at header.start has sequence >= start_seq
+     *
+     * Generally, the entry at header.start will have sequence
+     * start_seq if it exists.  The only exception is immediately
+     * after journal creation since the first sequence number is
+     * not known.
+     *
+     * If the first read on open fails, we can assume corruption
+     * if start_seq > committed_up_thru because the entry would have
+     * a sequence >= start_seq and therefore > committed_up_thru.
+     */
+    uint64_t start_seq;
 
     header_t() :
       flags(0), block_size(0), alignment(0), max_size(0), start(0),