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

merge fsync and j flags

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major - P3
    • Resolution: Works as Designed
    • None
    • None
    • Storage
    • None
    • Storage Execution

    Description

      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

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: