Use ext4 for a plain Linux server disk, and Btrfs when snapshots and checksums are the reason you are choosing a file system. ext4 is the mature, simple default: a journaling file system with decades of production use and very little to tune.
Btrfs is a copy on write file system with built in snapshots, data checksums, compression and multi device support. Those features are worth their extra complexity on a NAS, a desktop you want to roll back, or a backup target. Avoid Btrfs RAID 5 and 6.
- ext4 for a plain server disk, a VM disk or a database volume
- Btrfs when snapshots, rollback or data checksums are the point
- Btrfs checksums data. ext4 checksums metadata only
- The Btrfs documentation says RAID 5 and 6 should not be used in production
- XFS is the third option, strong for large files and big volumes
On this page
The defaultWhat ext4 is
ext4, the fourth extended file system, is the long standing general purpose file system for Linux. It is a journaling file system: changes to metadata are written to a journal first, so after a crash or power loss the filesystem replays the journal and comes back consistent in seconds instead of needing a full check.
ext4 stores files in extents, contiguous runs of blocks, which keeps fragmentation low. The Linux kernel documentation gives a maximum file size of 16 TiB with the usual 4 KiB block size. It checksums its metadata, so structural corruption is detected, but it does not checksum file data.
What ext4 does not do is the point of choosing it. There are no snapshots, no built in RAID, no compression and no subvolumes. Volume management comes from LVM and redundancy from mdadm or a hardware RAID controller.
Each layer does one job, every Linux tool understands it, and when something goes wrong, the recovery tools and the knowledge to use them are everywhere.
The alternativeWhat Btrfs is
What is Btrfs? The Btrfs documentation describes it as a modern copy on write filesystem for Linux aimed at advanced features while focusing on fault tolerance, repair and easy administration. Copy on write is the key idea: Btrfs never overwrites data in place. A change is written to a new location and the pointers are updated afterward.
That design is what makes its features cheap.
Snapshots. A snapshot shares all unchanged data with the original, so it takes seconds and almost no space. Snapshots can be read only or writable.
Subvolumes. Separate file system roots inside one Btrfs volume, each of which can be snapshotted on its own, for example root and home.
Checksums on data and metadata. Every block is checksummed, so Btrfs detects silent corruption. With a redundant profile such as RAID 1, it repairs the bad copy from the good one.
Scrub. A background pass that reads everything and verifies the checksums, repairing where a second copy exists.
Compression. Transparent ZLIB, LZO or ZSTD compression, set per mount or per file.
Send and receive. Snapshots can be streamed to another Btrfs file system, sending only the difference since the previous one.
Multi device support. One file system across several disks, with RAID 0, 1 and 10 profiles and online device add and remove.
SUSE's documentation for SUSE Linux Enterprise Server says Btrfs is the default file system for the operating system and XFS is the default for all other workloads, with snapshots enabled for the root file system. That split is a reasonable model: Btrfs where rollback matters, something simpler for bulk data.
The decisionBtrfs vs ext4: which one to choose
The Btrfs vs ext4 choice comes down to one question: do you need snapshots or data checksums from the filesystem itself? If not, ext4 is the better answer, because it is simpler, and simple fails less often and recovers more predictably.
A plain server disk. ext4. A web server, an application server or a VM whose disk is already snapshotted and backed up by the hypervisor gains nothing from Btrfs features.
Database and VM image volumes. ext4 or XFS. Copy on write fragments files that are rewritten in place all day. Btrfs can turn copy on write off for such files with the nodatacow option, but its documentation notes that nodatacow also turns off data checksums and compression, which removes most of the reason for using Btrfs.
A NAS or file server. Btrfs is a strong fit. Snapshots give users a way back from accidental deletion and ransomware encrypted files, and scrub catches disk corruption before it spreads into backups.
A Linux desktop or laptop. Btrfs, if the distribution sets up snapshots and rollback for updates. It turns a broken update into a reboot into the previous snapshot.
A backup target. Btrfs, for checksums that prove the backup data is intact and snapshots that keep several versions. Snapshots on the same disk are still not a backup, as the 3-2-1 backup rule explains.
WarningThe RAID 5 and 6 caveat
Btrfs includes its own RAID profiles, and they are not equally mature. The Btrfs status page lists RAID 1 and RAID 10 as OK for stability and lists RAID56, its name for RAID 5 and RAID 6, as unstable.
The Btrfs manual is direct about it. It says RAID56 has implementation and design deficiencies that make it unreliable for some corner cases, and that the feature should not be used in production, only for evaluation or testing.
It also names the write hole problem: an unclean shutdown can leave a stripe partly written, with parity that no longer matches the data.
For parity RAID on Linux, the usual answer is mdadm RAID or a hardware controller underneath, with ext4, XFS or single device Btrfs on top. For multi disk redundancy inside Btrfs, use RAID 1 or RAID 10. The page on RAID 5 vs RAID 10 covers the wider trade off.
Third optionWhere XFS fits
XFS vs ext4 is the other comparison people run into. XFS is a journaling file system like ext4, designed for large files, large volumes and many parallel writers. It is common for bulk data, media and large application data sets, and it is the default for data outside the root file system in the SUSE documentation mentioned above.
The practical differences from ext4 are few but real. XFS cannot be shrunk, only grown, so a volume that might need to get smaller later is better on ext4.
XFS has no snapshots or data checksums either. For most small business servers, ext4 and XFS are both sound choices, and the one your distribution installs by default is the one to keep.
PerformanceBtrfs vs ext4 performance
Btrfs vs ext4 performance depends on the workload, the kernel version and the mount options, which is why published benchmarks disagree. A few patterns follow from how each one works.
Rewrites in place. Databases and virtual machine images favor ext4 and XFS, because copy on write turns each overwrite into a new allocation and fragments the file over time.
Checksums and compression. Btrfs does more work per write. Compression can offset that on slow disks by writing less data, and costs CPU on fast ones.
Snapshots. Many snapshots on a busy file system add metadata overhead. Keep a retention policy instead of accumulating snapshots forever.
Full disks. Btrfs behaves worse than ext4 when nearly full, because copy on write needs free space even to delete or overwrite. Watch free space on Btrfs more closely.
For a file server on SSDs, the difference is rarely what users notice. For a database, it can be. Test with your own workload before deciding, or choose ext4 and avoid the question.
IntegrityChecking, repairing and data integrity
How each filesystem behaves when something is wrong matters more than throughput on the day it happens, and the two are not alike.
ext4 has one well worn repair path. e2fsck checks the filesystem offline and fixes structural damage, and a periodic check runs after a set number of mounts or months.
What it cannot do is tell you that a file's contents changed, because ext4 checksums its metadata and its journal, not your data. A bit that flips on the disk comes back as a successful read of wrong data.
Btrfs checks the data itself. Every data and metadata block carries a checksum, so a corrupt read is detected rather than returned. btrfs scrub walks the whole filesystem and verifies those checksums, and on a multi device profile with a second copy, such as RAID 1 or RAID 10, it repairs the bad block from the good copy.
On a single device there is nothing to repair from, so scrub reports the damage and names the affected file, which is still more than silence.
Btrfs repair is a last resort, not a routine. The project's own documentation is blunt about it: do not use btrfs check --repair unless a developer advises it. The normal recovery order is a mount with recovery options, then reading data off with the rescue tools, then restoring from backup.
What this means for storage you care about. If the data is irreplaceable and you want to know it is intact, Btrfs with a mirrored profile and a scheduled scrub tells you.
If the workload is a database or a VM image on an array that already has its own integrity checks, ext4 is the simpler filesystem and the array below does that job.
Neither of them replaces backups. A checksum tells you the file is damaged; only a backup gives it back, which is the point of the 3-2-1 backup rule.
PitfallsWhere people go wrong
Treating snapshots as backups. A snapshot lives on the same disks as the data. A failed array or a stolen server takes both. Snapshots complement immutable backups stored elsewhere, they do not replace them.
Using Btrfs RAID 5 or 6 for real data. The Btrfs documentation says not to. Use RAID 1 or 10 profiles, or parity RAID below the filesystem.
Running btrfs check with the repair option first. The btrfs check documentation says not to use the repair option unless a developer or an experienced user advises it. Try a scrub, a read only mount and restoring from backup first.
Letting a Btrfs volume fill up. Copy on write needs free space to do anything, including delete. Alert on free space well before the volume is full.
Converting a working ext4 server for no reason. A migration is a risk with no payoff if the server does not need snapshots or checksums.
Assuming ext4 detects bad data. It checksums metadata, not file contents. A disk that returns wrong data silently goes unnoticed on ext4 until someone opens the file.
ComparisonBtrfs and ext4, feature by feature
| Criterion | ext4 | Btrfs |
|---|---|---|
| Design | Journaling, updates in place | Copy on write |
| Maturity and simplicity | Very mature, simple | More features, more to understand |
| Snapshots | Only through LVM | Built in, instant, space efficient |
| Data checksums | Metadata only | Data and metadata, with scrub |
| Compression | No | ZLIB, LZO, ZSTD |
| Multi device RAID | Through mdadm or LVM | RAID 0, 1, 10 built in. Avoid 5 and 6 |
| Databases and VM images | Well suited | Needs nodatacow, losing checksums |
| Recovery tools and know how | Everywhere | Good, with more caution needed |
Two rows decide it. If snapshots or data checksums are what you need, Btrfs gives them to you in the filesystem itself and ext4 does not. If the volume holds databases or VM images, or nobody on the team knows Btrfs, ext4 is the lower risk choice.
FAQFrequently asked questions
What is the difference between Btrfs and ext4?
ext4 is a journaling file system that updates data in place and focuses on stability and simplicity. Btrfs is a copy on write file system with built in snapshots, data checksums, compression, subvolumes and multi device support. ext4 is simpler, Btrfs does more.
Ext4 vs Btrfs: which is better for a server?
For a plain server disk, a VM disk or a database volume, ext4. For a file server or NAS where snapshots and data integrity checks matter, Btrfs. Choose Btrfs for its features, not by default, since each feature is something else to understand and monitor.
What is Btrfs?
Btrfs is a copy on write file system for Linux. It never overwrites data in place, which lets it offer instant snapshots, checksums on all data and metadata, transparent compression, subvolumes and its own RAID profiles across several disks.
What is ext4?
ext4, the fourth extended file system, is a mature journaling file system for Linux. It stores files in extents, checksums its metadata and recovers quickly after a crash by replaying its journal. It is the long standing default on many Linux distributions.
Is Btrfs faster than ext4?
Not generally. Results depend on workload, kernel version and mount options. ext4 usually suits databases and virtual machine images better, because copy on write fragments files that are rewritten in place. Btrfs compression can help on slow disks by writing less data.
Is Btrfs stable?
Its core features, including snapshots, subvolumes, checksums and RAID 1 and RAID 10, are listed as OK on the Btrfs status page. Its RAID 5 and RAID 6 support is listed as unstable, and the documentation says not to use it in production.
Does ext4 support snapshots?
No, not by itself. Snapshots for an ext4 volume come from the layer underneath it, such as LVM snapshots, or from the hypervisor or storage system that hosts the disk. Btrfs builds snapshots into the file system.
XFS vs ext4: which should I use?
Both are mature journaling file systems. XFS suits very large files, large volumes and many parallel writers, but cannot be shrunk. ext4 is flexible and familiar. For a typical small business server, keep whichever your distribution installs by default.
Can I convert ext4 to Btrfs?
A conversion tool exists, but the safer route is to create a new Btrfs file system and copy the data across, with a verified backup taken first. For a server that works, ask whether you need Btrfs features before migrating at all.
Is a Btrfs snapshot a backup?
No. A snapshot sits on the same disks as the original data, so a failed disk, a lost server or an attacker with admin rights can destroy both. Keep separate backups, preferably with one copy offsite and one immutable.
Should I use Btrfs RAID 5?
No. The Btrfs documentation says its RAID56 profiles should not be used in production, citing design deficiencies and the write hole problem. Use Btrfs RAID 1 or RAID 10, or put parity RAID with mdadm or a hardware controller underneath the file system.
Which file system does a NAS use?
It depends on the vendor. Many NAS systems offer Btrfs for its snapshots and checksums, and ext4 for simplicity. If snapshots and self healing matter to you, choose the Btrfs option where the NAS supports it.
Keep readingRelated concepts
Read next · Disks and drives SSD vs HDD What the drive underneath is doing, and why it decides more about speed than the file system. Open this next12 min- Disks and drives · 11 min RAID 5 vs RAID 10 Parity and mirroring compared, which is the layer under the file system on most servers.
- Backup · 12 min Immutable Backups, and the Setting That Decides Whether They Work Backups that cannot be altered or deleted, and why a snapshot is not one.