When setting up a new Linux install with an SSD, many don’t know what file system to go with. This is understandable, as file systems are not talked about enough. When people install Linux, often times they select the default options without thinking about it. That’s not the right way to go about these things.
In this article we’ll go over the best file systems for your SSD on Linux. We’ll rank them and go over the positives and negatives of each.
1. Btrfs
Btrfs has many enemies. The detractors say it is unstable, and this can be true as it is in very heavy development. Still, it actually is a pretty solid file system for basic usage. especially when talking about solid state drives. The main reason is that Btrfs doesn’t journal unlike some other popular filesystems, saving precious write space for SSDs and the files on them.
The Btrfs filesystem also supports TRIM, a very important feature for SSD owners. TRIM allows for the wiping of unused blocks, something critical to keeping a solid-state drive healthy on Linux. Filesystem TRIM is supported by other filesystems. This really isn’t the main reason to consider Btrfs for your solid-state drive when using Linux.
A good reason to consider Btrfs is the snapshot feature. Though it is very true that the same thing can be accomplished on other file systems with an LVM setup, other filesystems do not come close to how useful it can be. With Btrfs, users can easily take snapshots of filesystems and restore them at a later date if there are any issues. For users looking for the best SSD support on Linux, it’s crazy not to at least give Btrfs a look.
2 EXT4
For those not looking for fancy features like “copy-on-write” or filesystem “snapshots” done the Btrfs way, Extended 4 may be a good choice for a solid-state drive. The reason that Ext4 is often recommended is that it is the most used and trusted filesystem out there on Linux today. It is used in massive data centers and in production, on all types of hard drives, including solid-state drives. If you’re a user that doesn’t care much about filesystems, do use this one.
However, the reason that it is not #1 on this list is for a simple reason. Extended 4 is not designed with SSDs in mind. It is true that it has file system trim support (a critical SSD feature), but outside of that the filesystem was never designed for this use case. Why? It uses a filesystem journal. This means that the filesystem is constantly writing logs down and informing the system of every single change. This can quickly wear out the limited write-space on an SSD running Linux.
Ext4 is a satisfactory choice for solid-state drives with filesystem journaling disabled, and a decent choice for most users, but it should not be the first choice.
3 XFS
One of the main reasons the XFS file system is used is for its support of large chunks of data. By far, XFS can handle large data better than any other filesystem on this list and do it reliably too. This is why XFS might be a great candidate for an SSD. As modern computing gets more and more advanced, data files get larger and more demanding. It makes sense to use a filesystem that can take into account all of this increase in data and do it reliably.
XFS, like Ext4, is a journaling filesystem. However, unlike Extended 4, it is not possible to disable journaling, thus it can be iffy to use on an SSD. Still, the filesystem is constantly called “high performance,” meaning it makes perfect sense to turn to this filesystem for high performance drives. Additionally, XFS supports standard SSD features and even defragmenting. SSD users unafraid of the journaling feature must take note of XFS when contemplating their new installation.
4 F2FS
F2FS is a filesystem developed by Samsung specifically for a new class of data storage: NAND. NAND is what people mean when they refer to “flash memory” and is how a solid-state drive stores data. F2FS is a relatively new, unknown technology. Despite this, it has already had some real success on Linux and elsewhere. Many F2FS fans seem to agree: why find a file system that plays nice with an SSD when there is one specifically built for it?
The downside to F2FS is that right now only power users can get it going. Most, if not all, Linux distributions do not support installing to it in their installation tools. The Linux kernel needs configuring and tweaking before usage. However, if you are a power user looking to get the most out of your solid-state drive on Linux, this is a filesystem you must look into. It might be a pain to set up, but it is worth it.
Conclusion
Solid-state drives are the new normal, but for some reason many Linux users are still unsure of what filesystems to go with, or even tweak them for better results. This is a shame. It is my hope that as solid-state drives become more prevalent on Linux, better filesystem choices within installers will follow.
Image credit: SSD_Questions,_Answered, Bonifacio_Global_City
15 comments
Journal writes are not a big issue on a new-ish generation SSD, as they can go through many more write cycles and the amount of data written is not that big. Moreover, there is also an option to move those logs to RAM instead. Is there any other significant factor that distinguishes these file systems with respect to SSD?
Thanks for article – How to disable journaling on ext4?
Don’t disable journalling on ext4. The article is simply wrong in saying that it is a problem – with a decent mid-level SSD, you can write to it continuously at high speed, for years with no sign of wear. With modern SSDs, it wear is pretty much a non-issue. Even with older or cheapo SSDs, you should keep the log – it is essential for file system integrity if there is a power failure or a crash.
BTRFS also has CRC’d data, ensuring data integrity.
I’ve been using BTRFS for abut 6 years now, both in RAID-1 and as individual drives, on multiple systems. Rotating drives and SSD. I’ve personally never experienced a BTRFS failure, even when drives fail (in the RAID-1 array).
In fact, BTRFS has saved me twice now – two drives several years ago that were corrupting data with no error returned by the drive hardware. The failures were silent on the drives when I was using EXT4 on them for backup. When I converted to BTRFS the filesystem began reporting CRC fails.
I’ll never go back to a filesystem that doesn’t CRC data blocks.
BTRFS has many useful features. CRC checks are not actually particularly relevant – it is extraordinarily rare that you would see a situation where BTRFS’s block CRC checks spot errors. Basically, you would be talking about drives with serious firmware bugs.
BTRFS has support for RAID – /that/ is what has saved your data, not the CRC check. You can use Linux mdadm raid along with other filesystems, but usually BTRFS RAID1 is more efficient than using mdadm to make a raid1 set and putting the BTRFS on top of that.
I also use BTRFS in RAID1 setups for most of my filesystems, on SSDs and HDs, for desktops and servers.
While you say it’s rare, I’ve encountered two drives that had silently failed. They were operating ‘normally’ under EXT4, but were corrupting data.
Rare things happen on occasion – /someone/ wins the lottery!
When data is stored on a hard disk, along with each block of 4K data there are hundreds of bits of redundancy to spot and correct all sorts of errors from the disk surface. The art of error detection and correction is complicated, but it’s easy to see that there is a very small margin for a surface error to pas undetected by the hundreds of bits of checking on the drive, and be spotted by the 32 bit CRC check at the filesystem level. It is the sort of thing you see at google’s data centres, not on /twice/ on a single machine.
So what /can/ cause failures that BTRFS CRC checks can spot? Bugs in drive firmware and its ERC routines are not unheard of, and may be a likely cause if both these failed drives are of the same type. Hardware problems on the main board, or overclocking too enthusiastically can cause errors during transfers. Memory problems will easily trigger CRC errors.
Normal, detectable disk read errors are a great deal more common, and RAID is the answer to fixing them. BTRFS’s CRC checks are cheap, and can catch obscure problems, so they are fine to have – even though most people will never encounter an error spotted by them.
cylinder of HD is causing more trouble by CRC check ..
Coming as it is from Samsung, f2fs gives me the creeps.
Disabling Journaling on EXT4 for fear of wear on SSD is cutting off your nose to spite your face. The EXT4 Journal constantly overwrites the same small set of blocks, so that can be a problem on drives with poor to no wear leveling, (ex. cheap sd cards or usb sticks used as system drive on Rasberry Pi projects.), but is a complete non-issue on Drives designed to run as system Drives, (ie, SSD Drives.)
The article is misleading in several ways, even though the conclusions are fine (IMHO).
BTRFS does the equivalent of journalling. In fact, the whole concept of a copy-on-write filesystem is that it works as a continuous journal. The purpose of the journal is to make it simple to recover consistency after a crash of some sort, and to avoid writes to one logical part of the filesystem harming other parts. (If you get a crash while writing to “foo.txt”, then it’s acceptable that “foo.txt” is empty or partially written – but /not/ acceptable that “bar.txt” gets damaged on the way.) A journal or log is a /good/ thing – you should never disable it.
BTRFS writes more to the disk than EXT4. For some kinds of files (especially virtual machine images), it writes a /lot/ more. That is still a good thing, because you are completely incorrect about worrying about wear. But it can make BTRFS a good deal slower for working with things like virtual machine image files, unless you disable COW for those files.
Modern SSDs of reasonable quality do not have issues with wear – they can be written continuously at high speed for years. Wear is only an issue for very low-end SSDs. Even then, you should not disable journalling or COW.
BTRFS has a number of other major advantages over other filesystems. You mentioned snapshots, which are important – and it should be noted that this is an instant operation. Other features include transparent compression (which can be a significant speed advantage when you have a fast processor and limited disk bandwidth, as well as getting more out of your SSD space), and built-in RAID1 when you have two disks. BTRFS also has optimisations for SSD drives – this has nothing to do with TRIM, but lets it organise data without the consideration of physical layout that is needed for HDs.
And you make the common mistake in thinking TRIM support in a filesystem is a good idea. It is not – issuing TRIM commands when files are deleted makes many types of operation a great deal slower due to the poor design of TRIM on SATA (it is much better on SCSI/SAS). For low or mid-level SSDs, it makes sense to regularly run a filesystem-wide “fstrim”, perhaps once each night or once each week. For high-end SSDs, even that will make little difference, though it will do no harm.
As far as I’m concerned, I’m good with EXT4. I have no issues with its seek times on my 1TB HDD and I don’t worry about errors or bad sectors because I have spares and a 4TB backup drive that holds images and snapshots of both my desktops and laptops. I know there might be a better alternative (BTRFS….XFS….ReiserFS etc.) But I’m from the school of “If It Ain’t Broke Don’t Fix It”!……Eventually I’m certain it will be impossible to find “spinning disc” hard drives unless you scour the bargain bins of eBay, or want to risk buying them from dodgy web-sites. In which case I’m sure by then(we HOPE!!) the SSD technology will have caught up with the times. Ahh….the price of using technology….you never get to enjoy something long enough because The Next Big Thing is eagerly waiting around the corner to shove The Current Big Thing off it’s throne!….(Remember when projector TV’s were The Big Thing?….they were huge….ran hot…and took up most of the living room space…..PLUS they cost….what?….like $3500.00?…when they first hit the market…..now?….you can’t buy ’em cause no one sells ’em anymore.) You might find one on eBay….but you’ll be screwed when it comes time for replacing parts! I’m wondering how much longer I’ll be able to find replacement keyboards for my Lenovo T-420 laptops, how long before they stop making the HDD I use in them now?…..Sad…because that was the “M-1 Abrams Tank” of the laptop world!….LoL!
To not being the first that jump on new technology band wagon are a good strategy. At least economically.
To wait until they stop make new ones are equally bad strategy, because when the stuff breaks, it can be at times when you really need it. So then you are forced to make the transaction over to the new stuff.
But whatever rocks your boat. ;-)
I agree with you that waiting until “Its Too Late” is not a good strategy, I straddle the line of not being too “far behind” and not being too “far ahead”…I try to secure hardware “in between” the years on both sides…….for instance…I am in the market for a laptop for a friend. I’m not looking at the 2017’s or the 2018’s….but I’m ALSO not looking at the 2016’s….I’m focused on the 2015’s…..since they have a life-expectancy of about 5-10 years….plus they’re adaptable to modern tech…(capable of 16GB RAM…upgradable to 32GB of RAM….eventually!)
Plus it can handle HDMI and video without glitches.,…since the video card drivers will have already been in existence for a few years now. Just being smart when it comes to technology. I know someone who LITERALLY waits until the “Day Of” a piece of hardware’s release in order to have it in his hands immediately, unfortunately for him?…9 times out of 10….he’s left “waiting” for some driver to be written….for some piece of developer code that was forgotten to be pushed out etc. What a terrible way to live. By the way?…he’s almost always broke!!!….LoL!
For my SSD I standardized on using btrfs. For two years now, I have not had a btrfs problem, but I have had issues with some Gnome extensions (written in javascript). I have moved ~/.cache/dconf to a non btrfs partition so as to eliminate Gnome problems.
One other thing that I have done, since my use is personal, is to add
@boot /sbin/fstrim -a
to the root crontab. and I do not use discard within the /etc/fstab. I also keep about 20 gigs of unused space on the SSD to insure wear-leveling.
If you are concerned with access speed from an SSD, then use ext4. Databases use zfs, but zfs is not universally available.
Thus, once a day or less often, when I reboot my desktop, I run fstrim for the SSD.