There is this guide for production servers:
https://docs.mongodb.com/manual/administration/production-notes/#kernel-and-file-systems
It tells that for the WiredTiger storage engine, XFS is strongly recommended against ext3 or ext4. But that article must be very old. Nowdays we are using Linux kernel 4. The 2.6 series of kernels date back to 2003. That is incredibly old.
So here comes the question: did something change in the last 14 years? (This sounds a silly question in the IT field, and it feels ridiculous to write down.) Is XFS still prefered for a production MongoDb cluster? Or should we use ext4 instead, or something else?
Best Answer
The provenance of information on the MongoDB production notes isn't apparent at the moment, but WiredTiger and the recommendation to use XFS was definitely added much later than the Linux kernel details. The production notes share collective experience from known issues, but are typically recommendations rather than strict guidance. Most notes are added at the time a widespread problem is observed, but circumstances could certainly change.
The specific recommendation against ext4 is based on observed stalls during WiredTiger checkpoints as reported by a number of production users. Per SERVER-18314 (May 2015), there is a likelihood of stalls when ext4 journaling coincides with WiredTiger checkpoints. This may not be an issue for all workloads, but is a significant enough caveat that a startup warning was added in MongoDB 3.4 (released Nov 2016) for deployments using ext4 with WiredTiger. There have been no similar reports with XFS, and it has been observed to generally perform better with MongoDB.
There are other available filesystems on Linux (ZFS, btrfs, ...) but these are currently not widely used in production (as compared to ext4 and XFS) so XFS is the recommended filesystem based on testing and experience.
While most distributions have moved on from the 2.6 kernel, there are some Enterprise stalwarts like RHEL6 that will not upgrade the default kernel during their release support lifecycle. Redhat does cherrypick and backport fixes with their own kernel subversion, but will remain on the original kernel base from the time of release. RHEL has a 10-year support policy followed by 4 years extended lifecycle support, so old versions tend to remain in the field much longer than you might expect. RHEL6 moves into extended support in 2020, so there are still new deployments using the 2.6 kernel in 2017. RHEL7 uses the 3.10 Linux kernel and won't reach extended support until 2024.