File system for an SSD drive
Solution 1
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
;
Solution 2
Recommended file systems in 2014
Few years have passed since this question was asked and the answers were posted. It's time to post some up to date info on this topic. If anything gets outdated, please post a comment.
Since this question was specifically "Is there a file system recommended today for SSD drives?" I will focus on answering that question and post links to other relevant info.
Currently (as of December 20, 2014) the Solid State Drives article on the Arch Linux wiki recommends the following filesystems:
Btrfs
Btrfs is a copy-on-write filesystem for Linux released under the GPL. Its development started at Oracle in 2007. It's included in the mainline since Linux 2.6.29 (March 2009). Currently the on-disk format is stable and is not expected to change.
- Btrfs official documentation in Torvalds tree
- Btrfs wiki on Kernel.org
- Btrfs on Arch Linux Wiki
- Btrfs on Wikipedia
ext4
ext4 (fourth extended file system) is a journaling file system for Linux, started as a series of backward compatible extensions to ext3 and later developed as the successor to ext3. The official plan of development for ext4 was published as Proposal and plan for ext2/3 future development work by Theodore Ts'o on Jun 2006. It's included in the mainline since Linux 2.6.19 (November 2006) and marked as stable since Linux 2.6.28 (December, 2008).
- ext4 official documentation in Torvalds tree
- ext4 wiki on Kernel.org
- ext4 on Wikipedia
- ext4 on Arch Linux Wiki
XFS
XFS is a 64-bit journaling file system created by Silicon Graphics in 1993, default in IRIX since 5.3 (1994), ported to Linux in 2001. Currently some Linux distributions use it as a default file system. XFS has TRIM support for SSDs.
- XFS official documentation in Torvalds tree
- XFS.org wiki
- XFS on Wikipedia
- XFS on Arch Linux Wiki
- XFS on Ubuntu Wiki
JFS
JFS is a 64-bit journaling file system created by IBM. IBM introduced JFS in AIX 3.1 in 1990. In 1999 it was released as open source and porting to Linux began. First stable version of JFS for Linux was released on June 2001. It was included in Alan Cox tree in 2.4.18pre9-ac4 and in mainline in 2.5.6 (2002). In 2012, TRIM Support was added to JFS.
2014 Benchmarks
- Linux 3.14 Kernel File-System SSD Benchmarks by Michael Larabel (February 2014)
- Linux 3.15 SSD File-System Benchmarks by Michael Larabel (May 2014)
- 9-Way File-System Comparison With A SSD On The Linux 3.17 Kernel by Michael Larabel (September 2014)
See also
- File systems optimized for flash memory, solid state media on Wikipedia
- Flash file system on Wikipedia
- Solid State Drives on Arch Linux Wiki
- Interview With the People Behind JFS, ReiserFS & XFS by Eugenia Loli (2001)
Solution 3
If available in your kernel and you are feeling adventurous you may wish to consider NILFS
Otherwise use ext4 but mount with noatime - see here for more tips.
Solution 4
You can use ext4 with the noload
mount option added to your /etc/fstab
file. It will make the filesystem behave as ext2 on steroids. In fact, AFAIK this is what Google uses in its data centers. You lose the safety net data journaling provides but you gain speed and longer life for your SSD.
You can make it permanent by running tune2fs -O ^has_journal
on the unmounted partition(s).
Related videos on Youtube
Elazar Leibovich
Updated on September 18, 2022Comments
-
Elazar Leibovich about 1 year
I always thought that traditional file systems, are geared and optimized for non-ssd drive, where, for instance, data locality is important, and fragmentation is problematic.
Is there a file system recommended today for SSD drives? Am I better off just using ext4?
-
Elazar Leibovich over 12 yearsWhat about
nodiratime
? -
Tok over 12 years@Elazar Leibovich - 'noatime' implies 'nodirtime'. If your question was in regards to the value of the latter over the former then certainly exempting directories from atime is better than nothing, but obviously the benefit will be less when compared to the former.
-
Stephen about 10 yearsI dunno - this seems like a lot of continued FUD about "write endurance". Even the most consumery drives will put up with at least 6 months of continuous writing of large data (SSD's are slow to write small changes). i.e. if it's a corporate file server, be concerned (tweak and get a good SSD). If it's a single user PC, then you'll want to replace your SSD in 5 years anyhow. That said, turning off atime etc will increase your performance (more over time)