[SERVER-11399] merge fsync and j flags Created: 28/Oct/13  Updated: 06/Dec/22  Resolved: 11/Nov/16

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Duraid Madina Assignee: Backlog - Storage Execution Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by DRIVERS-125 update description of 'fsync' write c... Closed
Assigned Teams:
Storage Execution
Participants:

 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


 Comments   
Comment by Eric Milkie [ 11/Nov/16 ]

Now that fsync is no longer documented anywhere, there is no incentive to merge it with j. Eventually we can consider removing support for it from the server.

Comment by Daniel Pasette (Inactive) [ 29/Oct/13 ]

We should update the documentation to describe the current behavior. Longer-term we can think about merging the options.

Generated at Thu Feb 08 03:25:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.