What Is the Most Common Linux File System?
If you've ever installed Linux and just clicked through the disk partitioning screen without thinking about it, you almost certainly ended up with ext4. That's not a bad outcome, but it's worth understanding why.
The short answer: ext4
Ext4 (Fourth Extended File System) is the most common file system on Linux by a wide margin. It ships as the default on Ubuntu, Debian, Linux Mint, Fedora (until recently), and dozens of other distributions. It's been the dominant choice since around 2008, when it replaced ext3 as the go-to option in most major distros. If you look at a random Linux desktop or server in the wild, odds are better than 7 in 10 that it's running ext4.
But "most common" and "best" aren't the same thing, and the gap between them is closing. Btrfs is now the default on openSUSE and Fedora Workstation (since Fedora 33 in 2020). That shift matters, because Fedora tends to preview where the broader Linux ecosystem is heading.
How Linux file systems actually work
A file system is the structure a operating system uses to store, organize, and retrieve data on a disk. It decides how blocks of storage get allocated, how file names and permissions are tracked, and what happens when your laptop loses power mid-write.
Linux uses a Virtual File System (VFS) layer, which is an abstraction that lets the kernel talk to many different underlying file systems using the same set of system calls. That's why you can mount an NTFS drive, an ext4 partition, and a FAT32 USB stick at the same time and access them all from the same file manager. The Linux kernel documentation on the VFS is dry reading, but it makes clear just how much architectural work goes into making this feel invisible to users.
The file system you choose affects journaling (which protects against corruption), snapshots, compression, and maximum file sizes. None of that matters much on a casual desktop. It matters a lot on a server or NAS.
The main Linux file systems, compared honestly
Ext4: reliable to the point of boring
Ext4 supports volumes up to 1 exabyte and individual files up to 16 terabytes. It uses journaling, which means it logs changes before committing them, so a sudden power cut is unlikely to corrupt your data. It's fast, well-understood, and supported by every Linux tool, live USB, and rescue environment you'll ever encounter.
The downsides are real, though. Ext4 has no native snapshot support. It doesn't do transparent compression. Online defragmentation is limited. If you want to shrink an ext4 partition, you generally have to unmount it first. These aren't dealbreakers for most people, but they're genuine limitations compared to newer options.
Btrfs: the future that keeps almost arriving
Btrfs (B-tree File System, pronounced "butter-fs" or "better-fs" depending on who you ask) has been in development since 2007 and was merged into the mainline Linux kernel in 2009. It offers copy-on-write semantics, built-in snapshotting, transparent compression, checksumming for data integrity, and the ability to manage multiple devices natively.
Fedora's switch to Btrfs in 2020 brought the file system to millions of desktops overnight. The main reason for that switch, according to the Fedora team, was automatic snapshots via Snapper or Timeshift, which means system rollbacks after a bad update become practical. That's a feature Windows users have had through System Restore for years, and Btrfs finally makes it straightforward on Linux.
The reputation for instability that Btrfs carried through the early 2010s is largely outdated now. Single-disk Btrfs is considered stable and production-ready. RAID 5/6 on Btrfs is still not recommended for critical data, but that's a specific edge case most desktop users will never touch.
It's FOSS has a solid breakdown of Btrfs features that's worth reading if you want a practical, non-kernel-developer explanation of what copy-on-write actually means for your workflow.
XFS: the server workhorse
XFS is the default file system on Red Hat Enterprise Linux (RHEL) and its derivatives, including CentOS Stream and AlmaLinux. It was developed by Silicon Graphics in 1993 and donated to Linux in 2001. XFS is extremely good at handling large files and high-throughput workloads, which is why it dominates enterprise storage environments.
On a desktop? You probably don't need it. XFS can't be shrunk at all (only grown), and its advantages show up most clearly at scale. But if you're setting up a file server or working with large media files, it's worth knowing it exists.
ZFS: powerful, complicated, and legally awkward
ZFS came from Sun Microsystems and is widely regarded as technically superior for serious storage work. It combines a file system and a volume manager, supports massive storage pools, and has extremely robust data integrity features. The problem is licensing: ZFS uses the CDDL license, which is incompatible with the GPL, so it can't be shipped in the mainline Linux kernel. Ubuntu includes it as an out-of-tree module, and OpenZFS maintains the Linux port actively. It's a great choice for a NAS or home server, but it's never going to be a default install option on a mainstream distro.
F2FS: specifically for flash storage
Flash-Friendly File System was developed by Samsung for solid-state storage, particularly eMMC chips in phones and embedded devices. Android uses it extensively. On a standard SSD laptop running a desktop distro, you're unlikely to need it, but it's worth knowing it exists if you work with embedded Linux systems.
Is ext4 or Btrfs faster?
This question comes up constantly, and the honest answer is: it depends on the workload, and the difference is rarely meaningful in practice for a desktop user.
In raw sequential read/write benchmarks, ext4 often edges out Btrfs slightly, partly because Btrfs spends CPU cycles on checksumming and copy-on-write operations. But Btrfs compression (zstd is the default) can actually make compressed workloads faster than ext4 on CPU-bound systems with slow disks, because reading a smaller compressed file from disk is faster than reading a larger uncompressed one.
Phoronix, which runs the most systematic Linux benchmarks available to the public, has published multiple comparisons over the years. Their results consistently show that the performance difference between ext4 and Btrfs on modern NVMe storage is typically under 5% in real-world mixed workloads. At that margin, features (snapshots, compression, integrity checking) should drive the decision more than raw speed numbers.
For database workloads or anything doing massive random I/O, XFS or ext4 typically beat Btrfs. For a general-purpose laptop or workstation, Btrfs is fine and the snapshot capability is genuinely useful.
Does Linux prefer NTFS or exFAT?
Linux doesn't "prefer" either one, but it runs both. NTFS is a Windows file system, and Linux reads and writes it via the NTFS-3G driver (or, since kernel 5.15, via the new Paragon NTFS driver merged into the mainline kernel, which is meaningfully faster). ExFAT is supported natively since kernel 5.4.
For a drive you want to share between Linux and Windows, exFAT is actually the cleaner choice for external drives and USB sticks. It doesn't have the complexity of NTFS, Windows handles it well, and Linux support is solid. FAT32 is the other option, but its 4GB file size limit makes it a non-starter if you're moving large files around.
Neither NTFS nor exFAT should be your root partition. They don't support Linux file permissions, ownership, or symbolic links properly. Your Linux install needs to live on ext4, Btrfs, XFS, or another native Linux file system.
If you're thinking more broadly about getting comfortable with Linux's disk and file structure, the guide on how to free up disk space on Linux covers the practical side of managing partitions and storage without breaking your system.
What file system should you actually use?
For a new desktop or laptop install in 2025: use whatever your distro defaults to. If that's ext4, you're fine. If it's Btrfs (Fedora, openSUSE), you're also fine, and you get snapshots as a bonus.
For a home server or NAS: ZFS (via OpenZFS) or Btrfs are both worth considering. ZFS has a steeper learning curve but mature tooling. Btrfs is easier to set up and integrates naturally with most distros.
For an external drive shared between Linux and Windows: exFAT. Don't overthink it.
For a production database server: ext4 or XFS. Btrfs copy-on-write doesn't play nicely with database write patterns, and most database vendors specifically recommend disabling it or using a different file system for data directories. PostgreSQL's documentation on storage, for instance, doesn't prescribe a specific file system but the community consensus for years has been ext4 or XFS for serious deployments.
The ext4 vs Btrfs question, practically speaking
Here's the real trade-off: ext4 will never surprise you. It's been stable for 15+ years, every sysadmin knows it, and every tool supports it perfectly. Btrfs will occasionally require you to learn something new, whether that's understanding subvolumes, running btrfs balance periodically, or figuring out why your disk usage reports look weird (copy-on-write and snapshots make traditional disk usage tools confusing).
That learning curve is worth it if you want rollbacks. It might not be worth it if you just want a file system that stays out of your way. Both are completely reasonable positions.
What's clear is that ext4's reign as the unchallenged default is ending, slowly but deliberately. Fedora made the call five years ago. The rest of the mainstream desktop distros will follow eventually. Learning how Btrfs works now means you won't be caught flat-footed when Ubuntu eventually flips the switch.