-
Type: Improvement
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Storage
-
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
- is depended on by
-
DRIVERS-125 update description of 'fsync' write concern flag
- Closed