While a node is under fsyncLock, no journal flushes happen, so the journal listener never fires and durableOpTime stays behind lastWritten. With featureFlagReplicatedFastCount enabled this is visible as a failure in fsync.js, which is why that test was excluded in SERVER-133082.

The initial iteration on SERVER-126254 attempted to fix this by advancing the durable optime from the fsync code path. That was reverted because it advanced the durable optime for writes that had not been made durable in a way that survives startup recovery. On recovery we truncate the oplog at the oplog truncate after point unconditionally, so advancing the durable optime without a matching truncate after point update lets a node acknowledge, and potentially majority commit, an entry that a restart will truncate away. BF-45325 hit exactly that and produced a rollback of majority committed data.

Once SERVER-126254 is properly fixed we can re-enable fsync with replicated fast count.