File system type and mount options for Archlinux on NVMe SSD drive

If the SSD is to be your only disk platform, regardless of number of devices, then you have a quandry; how to minimize writes while maintaining reliability and performance.

More specifically, ext4, and 3 for that matter, NILFS, and almost any other modern file system will maintain a journal. Ordinarily this is desirable, however, when dealing with SSD devices it increases the writes performed against the device and thereby reduces its lifespan. One option is to select a conventional IDE, SATA, or other device to which the file system can write its journal. This way one may maintain the benefits of journaling without sacrificing lifespan of the SSD device(s). In the case of ext4 this can be accomplished as: mke2fs -O journal_dev /dev/external_device then attached to the specific file system as: mkfs.ext4 -J journal=/dev/external_device. More information can be found in the man page.

An additional feature of file systems to keep in mind when deal with SSD devices is atime. Setting atime on a file system can drastically increase the number of writes to a given device over time. Options for changing this behavior include 'relatime' and 'noatime'.

Since we seem to be focusing on ext4, the kernel documentation on the file system, including its available options, is available for reference here.

Some other options to consider: noload, as vorbote suggested, and errors=remount-ro;

Re overprovisioning - all you need to ensure is that the SSD itself has a sufficient number of blocks that it knows are unused. It's unimportant whether it knows that because a) they're unused because they're in unpartitioned space so have never been written to by the OS, or b) they've had zeros written to them and the SSD firmware implements hueristics to detect that and consider them unallocated, or c) they've been the target of a DISCARD ('trim') operation. Any (and only) one of these is highly advisable.

Re noatime: I find that I personally don't care about files' last-access times, and no software I use seems to care either. So I mount everything with 'noatime'. There are vague references on the Internet about unnamed programs that malfunction if 'noatime' is used, but I've never seen such a program.

Re trim/discard: You should run fstrim periodically. It doesn't matter how it is invoked, but it does matter how frequently it is invoked. Running it at each boot, eg using rc.local, would probably be excessive, unless you reboot very infrequently or you use, then free up, disk space very frequently, or both. Do not mount with 'discard', because it causes the kernel to perform TRIM operations close to the time blocks are freed, which is probably a time when you are likely to notice the increased latency it causes. You are less likely to notice or care about a cron job running at (let's say) 3am. I imagine that once a month would be more than sufficient for an average desktop workload, or once a week for a write-heavy desktop workload. I don't know of any perfect way to know when an fstrim is advisable, because the details of block allocation are usually hidden by the drive firmware. If you observe significant slowing of the drive's performance, an fstrim would be a good thing to try. If you don't notice a slow-down, the you probably don't need to do anything.

Re I/O scheduler - benchmark the workloads you care about. There is no substitute for empirical evidence.

Re swap - RAM is quite cheap nowadays, so I and my employer buy large amounts of it - at least 16GB per machine I build for home use, and at least 256GB in the servers at work. For all workloads on all machines I encounter both at home and at work, everything fits comfortably in RAM, with plenty of room to spare for cache. Thus I disable swap at home and at work. Additionally, using swap would cause a performance decrease which would be unacceptable both to me and to our users, and which would therefore cause me or my employer to urgently go and buy even more RAM. So I never want to use swap - it attempts to hide a lack-of-RAM problem that I'd rather solve. I can't comment on your position. I imagine it could be similar.

Lastly, I disable, or even uninstall, many services which are installed and enabled by default on popular Linux distributions. This saves some virtual memory, but perhaps more importantly, it 'hardens' the machine against attack. If this is done religiously, there should be little to nothing worthless in RAM that could be swapped out to disk without sacrificing performance.