Description

We recommend moving the journal to a separate mount for performance reasons and as part of our best practices but omit providing guidance on sizing of this mount.   The consequence of this is the generation of unnecessary  Support cases and inconsistent responses.

Under steady-state conditions we need to keep at least "dirty data generated and journaled between checkpoints". 

Starting in 4.0 we journal only OpLog entries.  Therefore, using OpLog churn metrics as a proxy we can provide some actual guidance.

Under steady-state I'd use 10 min * oplog churn/min.  I would then recommend the customer think about downtime requirements where a majority commit point is not moved forward for some extended period of time (due to maintenance or downtime).  In that case, we should plan for hours to days of "window" and size accordingly.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)