Btrfs is a copy-on-write filesystem for Linux that combines a filesystem with volume management features such as subvolumes, snapshots, data checksums, transparent compression and support for multiple devices. Its name comes from the B-tree data structures it uses for nearly all metadata, and it is commonly pronounced as butter FS or better FS.
Development began in 2007, and Btrfs entered the mainline Linux kernel in 2009. It is the default root filesystem on openSUSE and on Fedora Workstation, where its snapshots and compression are used for system rollback and space savings. Among Linux filesystems, it is the main in-kernel alternative to ext4 and XFS for users who need integrity checking and cheap snapshots.
How copy-on-write works in Btrfs
In a traditional filesystem such as ext4, modified data is usually written in place, overwriting the old blocks. Btrfs instead writes changed data and metadata to new locations and then updates the tree pointers that reference them. The old blocks remain valid until nothing refers to them anymore.
This design has three direct consequences. The filesystem moves from one consistent state to the next, so a crash leaves either the old or the new version intact. Snapshots are nearly free, because a snapshot is just another reference to the existing trees. Finally, every block can carry a checksum that is verified on read, so silent corruption is detected instead of passed to applications.
| Feature | What it does | Practical benefit |
|---|---|---|
| Subvolumes | Independent file trees within one filesystem | Separate root, home and data without fixed partitions |
| Snapshots | Point-in-time copies of a subvolume | Instant rollback and consistent backups |
| Checksums | CRC32C by default, also xxHash, SHA-256, BLAKE2b | Detects silent data corruption |
| Compression | zstd, LZO or zlib per file or mount | Saves space and often reduces I/O |
| Send and receive | Streams differences between snapshots | Efficient incremental replication |
| Online resize and device add | Grows, shrinks or adds disks while mounted | Storage changes without downtime |
Multi-device profiles and their reliability
Btrfs can span several block devices and store data and metadata with different redundancy profiles. Because it knows checksums for each block, a redundant profile can repair a corrupted copy automatically from a good one, which a conventional RAID layer below the filesystem cannot do.
| Profile | Copies or parity | Minimum devices | Maturity |
|---|---|---|---|
| single | One copy | 1 | Stable |
| DUP | Two copies on the same device | 1 | Stable, default for metadata on single disks |
| RAID1 | Two copies on different devices | 2 | Stable |
| RAID1C3 and RAID1C4 | Three or four copies | 3 or 4 | Stable |
| RAID10 | Striped mirrors | 2 or more | Stable |
| RAID5 and RAID6 | Single or double parity | 2 or 3 or more | Not recommended for production |
The parity profiles have long suffered from a write hole problem and other edge cases, and the kernel documentation still advises caution. Administrators who need parity redundancy usually combine Btrfs with mdraid underneath or choose RAID1-style profiles for data and metadata.
Btrfs compared with other Linux filesystems
Each major Linux filesystem reflects different priorities. Btrfs trades some raw write performance and simplicity for integrity and flexibility features.
| Filesystem | Design | Snapshots | Data checksums | Typical use |
|---|---|---|---|---|
| Btrfs | Copy-on-write, B-trees | Native, subvolume level | Yes | Desktops, NAS, snapshot-based rollback |
| ext4 | Journaling, in-place writes | Only through LVM | Metadata only | General-purpose default |
| XFS | Journaling, allocation groups | Only through LVM | Metadata only | Large files and parallel I/O |
| ZFS | Copy-on-write pooled storage | Native, dataset level | Yes | Storage servers; out-of-tree module |
Btrfs and ZFS share many ideas, but Btrfs is part of the mainline kernel, while ZFS is maintained outside it for licensing reasons. ZFS is generally regarded as more mature for parity RAID, whereas Btrfs offers more flexible device mixing and in-place reshaping of profiles.
Maintaining and tuning a Btrfs filesystem
Btrfs needs some routine maintenance that ext4 users rarely think about. Disk space is allocated in chunks for data and metadata, so df can be misleading; btrfs filesystem usage shows the real allocation.
- Run a scrub regularly, often monthly, to read all blocks, verify checksums and repair from redundant copies.
- Use a filtered balance when metadata space runs out while data chunks are half empty.
- Disable copy-on-write with
chattr +Cfor virtual machine images and some databases to avoid fragmentation. - Limit snapshot counts with tools such as Snapper, because hundreds of snapshots slow down some operations.
- Enable zstd compression, for example level 1-3, which usually saves space with little CPU cost.
A common layout places the root filesystem and home directories in separate subvolumes, often named @ and @home. This lets the system roll back the root subvolume after a failed update without touching user files, and it allows different snapshot schedules for system and personal data. Swap files are supported, but they must live in a subvolume with copy-on-write disabled and cannot be included in snapshots.
Limitations and common mistakes
The most important misconception is that snapshots are backups. A snapshot lives on the same devices as the original data, so a failed disk or a deleted filesystem takes both away. Real backups require copying snapshots elsewhere, for example with send and receive.
Other pitfalls include relying on RAID5 or RAID6 profiles for critical data, ignoring out-of-space conditions caused by full metadata chunks, and running write-heavy databases on default copy-on-write settings. Disabling copy-on-write for a file also disables its checksums and compression, which is an accepted trade-off rather than a free optimization.
A non-technical view
Btrfs is a way for Linux to organize files on a disk. Its key trick is never overwriting old data directly. It writes changes to a new place first and then switches over.
Because of this, it can take a photo of the whole system in an instant. If an update breaks something, the computer can go back to that earlier photo. It also checks every piece of data for damage when reading it.
A concrete example
A home lab user runs a small file server with two 8 TB disks formatted as Btrfs with the RAID1 profile and zstd compression. Snapper takes hourly snapshots of the shared folders and keeps them for two weeks, and a monthly scrub runs automatically.
During one scrub, Btrfs reports checksum errors on one disk in a few blocks of family photos. Because a second good copy exists on the other disk, the filesystem repairs the damaged blocks automatically. The user replaces the failing disk with btrfs replace while the server stays online, and no file is lost. Nightly send and receive copies to an external drive provide the separate backup that snapshots alone could not.