If jstests/core/fsync.js throws an assertion after calling fsyncLock, but before calling fsyncUnlock, the server will be left in an fsyncLocked state. This can be a problem if multiple tests are being run in parallel, or --continueOnFailure is being used (resmoke will get stuck waiting for the fsyncLocked mongod).

The exception to this is asserting if the fsyncLock has failed. This is safe as long as the server wasn't already fsyncLocked when fsyncLock was called (ie. testing recursive fsyncLock).

Many of the tests have the kind of form you would expect:

• fsyncLock
• do stuff/check something (ie. call assert())
• fsyncUnlock

Better would be to rearrange things so as to never call assert() between fsyncLock/fsyncUnlock, eg:

• fsyncLock
• save values to be tested
• fsyncUnlock
• check saved values (ie. call assert())

The main alternative to this approach would be to pass a "finally" function to assert(), which is called just before doassert(). But this would be more invasive (and probably uglier) than just fixing this one jstest.