What’s the Best File System for My Linux Install?

What's the Best File System for my Linux Install?

File systems: they’re not the most exciting things in the world, but important nonetheless. In this article we’ll go over the popular choices for file systems on Linux – what they’re about, what they can do, and who they’re for.



If you’ve ever installed Linux before, chances are you’ve seen the “Ext4” during installation. There’s a good reason for that: it’s the file system of choice for just about every Linux distribution available right now. Sure, there are some that choose other options, but there’s no denying that Extended 4 is the file system of choice for almost all Linux users.

What can it do?

Extended 4 has all of the goodness that you’ve come to expect from past file system iterations (Ext2/Ext3) but with enhancements. There’s a lot to dig into, but here are the best parts of what Ext4 can do for you:

  • file system journaling
  • journal checksums
  • multi-block file allocation
  • backwards compatibility support for Extended 2 and 3
  • persistent pre-allocation of free space
  • improved file system checking (over previous versions)
  • and of course, support for larger files

Who is it for?

Extended 4 is for those looking for a super-stable foundation to build upon, or for those looking for something that just works. This file system won’t snapshot your system; it doesn’t even have the greatest SSD support, but If your needs aren’t too extravagant, you’ll get along with it just fine.



The B-tree file system (also known as butterFS) is a file system for Linux developed by Oracle. It’s a new file system and is in heavy development stages. The Linux community considers it unstable to use for some. The core principle of BtrFS is based around the principle of copy-on-write. Copy on write basically means that the system has one single copy of a bit of data before the data has been written. When the data has been written, a copy of it is made.

What can it do?

Besides supporting copy-on-write, BtrFS can do many other things – so many things, in fact, that it’d take forever to list everything. Here are the most notable features: The file system supports read-only snapshots, file cloning, subvolumes, transparent compression, offline file system check, in-place conversion from ext3 and 4 to Btrfs, online defragmentation, anew has support for RAID 0, RAID 1, RAID 5, RAID 6 and RAID 10.

Who is it for?

The developers of BtrFS have promised that this file system is the next-gen replacement for other file systems out there. That much is true, though it certainly is a work in progress. There are many killer features for advanced users and basic users alike (including great performance on SSDs). This file system is for those looking to get a little bit more out of their file system and who want to try the copy-on-write way of doing things.



Developed and created by Silicon Graphics, XFS is a high-end file system that specializes in speed and performance. XFS does extremely well when it comes to parallel input and output because of its focus on performance. The XFS file system can handle massive amounts of data, so much in fact that some users of XFS have close to 300+ terabytes of data.

What can it do?

XFS is a well-tested data storage file system created for high performance operations. Its features include:

  • striped allocation of RAID arrays
  • file system journaling
  • variable block sizes
  • direct I/O
  • guaranteed-rate I/O
  • snapshots
  • online defragmentation
  • online resizing

Who is it for?

XFS is for those looking for a rock-solid file solution. The file system has been around since 1993 and has only gotten better and better with time. If you have a home server and you’re perplexed on where you should go with storage, consider XFS. A lot of the features the file system comes with (like snapshots) could aid in your file storage system. It’s not just for servers, though. If you’re a more advanced user and you’re interested in a lot of what was promised in BtrFS, check out XFS. It does a lot of the same stuff and doesn’t have stability issues.



Reiser4, the successor to ReiserFS, is a file system created and developed by Namesys. The creation of Reiser4 was backed by the Linspire project as well as DARPA. What makes Reiser4 special is its multitude of transaction models. There isn’t one single way data can be written; instead, there are many.

What can it do?

Reiser4 has the unique ability to use different transaction models. It can use the copy-on-write model (like BtrFS), write-anywhere, journaling, and the hybrid transaction model. It has a lot of improvements upon ReiserFS, including better file system journaling via wandering logs, better support for smaller files, and faster handling of directories. Reiser4 has a lot to offer. There are a lot more features to talk about, but suffice it to say it’s a huge improvement over ReiserFS with tons of added features.

Who is it for?

Resier4 is for those looking to stretch one file system across multiple use-cases. Maybe you want to set up one machine with copy-on-write, another with write-anywhere, and another with hybrid transaction, and you don’t want to use different types of file systems to accomplish this task. Reiser4 is perfect for this type of use-case.


There are many file systems available on Linux. Each serves a unique purpose for unique users looking to solve different problems.This post focuses on the most popular choices for the platform. There is no doubt there are other choices out there for other use-cases.

What’s your favorite file system to use on Linux? Tell us why below!


  1. I have used JFS for my media filesystems for many years. I used to use XFS for that purpose for a couple of years but it was less stable then and I suffered data loss – I presume XFS is better now but JFS has been rock solid for me.

    1. JFS is a bad idea. Besides not being actively developed anymore, it has no checksum on its journal! Let’s say your PC crashes. All of your data is fine; however, the journal (where it records transactions before executing them) gets garbled. Without any way to know the log is corrupt and should be disregarded on reboot, JFS says “Oh, I was going to copy and #&$#&^$#&*(@@…. ok!” and then proceeds to attempt to execute the corrupted instructions, screwing up an otherwise clean file system!

      You can test this out yourself if you wish. Back in 2010 I was new to Linux and decided to install JFS along with a rolling-release Linux distro. At that time said distro was unstable on my system, and I had many lockups. Every time I’d reboot, my KDE desktop was set back to default settings! I thought this was a KDE or Linux problem and wanted to know how everyone else dealt with it. No one else, of course, had their KDE resetting all the time. It was only after some more digging that I learned about how dangerous to your data JFS can be during system crashes. KDE was opting to reset its config files upon finding corruption, which was why my desktop would return to defaults after the crashes. Switching to a stable distro stopped the lockups, and switching to ext4 (today BtrFS) kept my data safe.

      Wikipedia: “The internal format of the journal must guard against crashes while the journal itself is being written to. Many journal implementations (such as the JBD2 layer in ext4) bracket every change logged with a checksum, on the understanding that a crash would leave a partially written change with a missing (or mismatched) checksum that can simply be ignored when replaying the journal at next remount.”

      Wikipedia also notes in regard to JFS: “JFS journals metadata only, which means that metadata will remain consistent but user files may be corrupted after a crash or power loss. JFS’ journaling is similar to XFS where it only journals parts of the inode…. There are also potential problems with JFS, such as its implementation of journal writes. They can be postponed until there is another trigger – potentially indefinitely, which can cause data loss over a theoretically infinite timeframe.”

      JFS’ performance is fine, but it is lacking modern data safety features.

      1. For a media filesystem JFS is good enough since if the system crashes the content is borked anyway so I don’t care about the data currently being written. On the other hand the filesystem is really broken if the metadata is corrupted. EXT4 I find is too slow for media e.g. recording OTA probably because of the journaling, etc. but it is my choice for system disks. Like I said I used to have a lot of problems with XFS not recovering after crashes or worse freezing which prompted my change to JFS which has performed much better for my purposes. I tried ZFS 3 or 4 years ago using FreeBSD but could never get it to recover properly from lost disks and it seemed slow. I haven’t tried it recently since my needs have been met with JFS.
        I try to choose a filesystem that meets my particular needs and performs well within my parameters. A journal just speeds up the process of filesystem cleanup i.e. making sre the metadata is consistent – the filesystem metadata can still be repaired without a journal albeit with data loss. I find the description of JFS trying to use a corrupted the journal and destroying a clean filesystem surprising and not consistent with my experience but it’s may be because I use a UPS on my media server and most of my crashes are a result of power outages which tend to stop my media recording before the server crashes.

    2. JFS caused me small data loss several times after power-offs, it was a root filesystem (kernel was somewhat 3.7-3.8), options were default. So I’ve quickly moved away from JFS to BTRFS, cause JFS is unsupported. This “Butter FS” was fine, but slow at seeking files in large FS. Then I’ve moved back to EXT4 (rock solid and faster in seeking files for my spinning HDD). BTW, e4rat allowed me to decrease boot time on my desktop system, so I’m happy with EXT4, despite of lack BTRFS COW features.

  2. You made no mention of ZFS, which offers many advantage, eg better than RAID5/6 data protection, ability to correct bit-rot, rxtrrmly large file and file-system sizes, snap-shots, and many other features. Developed by SUN for Solaris, available so opnsource via the openZFS project.

  3. I’ve been using Linux since 2000. I’ve been using ReiserFS since not long after 2000. I’ve found through experience, it’s *the* most stable FS there is.

    For example, I live out in the woods…literally. Power outages and brown-outs are a fact of life. Before I knew about UPS’s (probably went the first 8 years of having computers w/out one, ’95-’03 I think). Every time, *EVERY* time, the power went out, all I had to do was boot back up and my Linux would start. Very rarely has it ever needed an fsck done.

    I can’t say that that was so with any of the other FS’s I’ve used – ext2, ext3, and xfs and jfs IIRR. None of them held up after any power outage. Major work had to be done to be able to get back into my system, and a few times it was futile and I had to reinstall and lost everything on my hdd’s (luckily I back-up regularly!).

    I’ve not had the chance to try reiser4, but as soon as Slackware comes out with its next version, I’m going to give it a shot (been using Slack since 13.37). No matter what though, after years of experience and not once having lost data by using reiserFS, can anyone make me change to another. It ‘Just Works’ and does it well.

  4. I’ve used most common Linux filesystems over the years, including ReiserFS. My current personal system is a mix of Ext4 and ZFS. I have one big server where I work that has a 24 TB XFS filesystem (I would have used ZFS if I had been allowed to build the system!). So far, no problems. In fact, I have never lost data (In the 18 years I have been running various flavors of Linux) on any Linux filesystem!

Comments are closed.