Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-11399

merge fsync and j flags

    • Type: Icon: Improvement Improvement
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Storage
    • Labels:
      None
    • Storage Execution

      Currently we handle the 'fsync' and 'j' flags as follows: (write_concern.cpp)

              if ( cmdObj["j"].trueValue() ) {
                  if( !getDur().awaitCommit() ) {
                      // --journal is off
                      result->append("jnote", "journaling not enabled on this server");
                      // Set the err field, if the result document doesn't already have it set.
                      if ( !err ) {
                          result->append( "err", "nojournal" );
                      }
                      return true;
                  }
                  if( cmdObj["fsync"].trueValue() ) {
                      *errmsg = "fsync and j options cannot be used together";
                      return false;
                  }
              }
              else if ( cmdObj["fsync"].trueValue() ) {
                  Timer t;
                  if( !getDur().awaitCommit() ) {
                      // if get here, not running with --journal
                      log() << "fsync from getlasterror" << endl;
                      result->append( "fsyncFiles" , MemoryMappedFile::flushAll( true ) );
                  }
                  else {
                      // this perhaps is temp.  how long we wait for the group commit to occur.
                      result->append( "waited", t.millis() );
                  }
              }
      

      This behavior ("fsync means sync using a journal if present otherwise the datafiles") seems reasonable but if so:

      • We should move towards having just one flag - sync - instead of two
      • We should update our docs (both manual + driver docs)

      The thinking here is:

      • Users really just want a bool "sync this write" and don't really care how it happens.
      • Even if it does make sense to allow users to adjust how their data is synced, the current code doesn't really allow it but the docs (and arguably the flag names) make it sound like there is always a real difference between e.g. (in the Java driver) FSYNC_SAFE and JOURNAL_SAFE

            Assignee:
            backlog-server-execution [DO NOT USE] Backlog - Storage Execution Team
            Reporter:
            duraid.madina@10gen.com Duraid Madina
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: