When installing an OS and reaching the disk partitioning and formatting step, a screen full of file systems appears, and most people habitually hit Enter to pick ext4. Right next to it, Btrfs has actually been sitting quietly all along, though many people glance at it and skip right past. It’s also responsible for writing data to physical disks, but its temperament couldn’t be more different from classic file systems.
Simply put, this whole temperament is determined by a single low-level write action. Btrfs never modifies a file by overwriting it in place; instead, it finds a blank area on the disk, writes the new content there, and then moves the upper-level pointer over, leaving the old content safely sitting in place. Just this simple action bought all of its signature tricks and simultaneously ran up all the bills down the road. Once you thoroughly grasp this exchange, you won’t need to memorize a single command to see clearly how it evolved step-by-step into its current form, and you’ll naturally know whether to choose it for the machine in your hands in 2026.
To understand Btrfs, you have to look back to 2007 and see what trouble spots Linux storage was agonizing over back then. At that time, the whole community was facing several tough pain points.
The most direct catalyst came from the camp next door. In 2005, Sun launched ZFS, integrating snapshots, data checksumming, and multi-disk storage pools into a single layer—a move that sent shockwaves through the entire storage industry. As envious as the Linux side was, ZFS’s license was incompatible with the Linux kernel, meaning the code couldn’t be merged into mainline, and it also carried patent risks overhead. At the time, core kernel developer Andrew Morton even publicly criticized such a design as a layer violation—a quote that only spread after being relayed by OSNews. To get similar capabilities, Linux had no choice but to roll up its sleeves and build from scratch on its own.
Another headache was that full disk checks took way too long. File systems keep bookkeeping on disk, and sudden power outages easily scramble the accounts, requiring a full disk check upon reboot before anyone dares to use it. As disk capacities grew year after year, check times scaled up right along with them. The Linux community had already learned this lesson the hard way: Ted Ts’o, who later led ext4 development, recalled that as early as 2000 and 2001, scanning 40 to 80 GB drives was already driving people crazy. Outcries from the community directly spawned ext3 with journaling, avoiding full disk checks after power failures by replaying logs. But this trick only eliminated the check step without touching the deeper problem: the ext family only cares whether the bookkeeping metadata is correct and never bothers with file content itself. If a drive silently outputs corrupted data, as long as the format complies with standards, the system has absolutely no way to detect it.
There was also an agonizing hassle: building with stacked blocks. If you wanted snapshots, you had to carve out logical volumes with LVM at the bottom; if you wanted multi-disk redundancy, you had to add an md array layer; and then the file system was slapped on top. The three layers operated independently, unaware of each other. A forum comment retained an operation checklist from back then: doing a routine partition resize meant unmounting, running a check, shrinking the file system, and then shrinking the logical volume—typing four or five commands in a row while praying that the two tools’ math on capacity numbers wouldn’t clash.
In November 2007, file system engineers from various companies gathered for a workshop, where the explicit topic on stage was ZFS’s overwhelming marketing blitz. Everyone agreed on two paths right there on the spot: in the short term, add extensions to ext3 to create ext4 (which turned stable the following year); in the long term, start fresh to build a new file system supporting snapshots and checksums. The short-term path was indeed delivered: ext4 managed to shrink a check that took 45 minutes on ext3 down to 4 or 5 minutes, but file content itself remained unmonitored—exactly the hole the long-term route needed to fill. After weighing options, they picked Btrfs, which Oracle engineer Chris Mason had just kicked off. Ts’o poured cold water on everyone at the meeting, stating bluntly that an enterprise file system takes 50 to 200 person-years and five calendar years, noting ZFS itself started work in 2001 and was only served up in 2006. Back then, terrified of scaring away financial backers, everyone beat their chests and swore it could be done in two or three years. Looking back later, Ts’o noted that distros didn’t approve it for consumer readiness until the fall of 2012—not a single day short, taking five full years.
All mechanisms in Btrfs stem from a single action: modifying a file never overwrites old data on disk. With every modification, it writes the updated content into a blank location first, waits until all data has landed on disk, and only then updates the entry pointer pointing to it. This pattern is called Copy-on-Write (CoW)—write the new first, then move the pointer. Until the pointer moves, the original data stays untouched; once the pointer flips, the new content takes effect instantly. The old data quietly remains in place until nothing references it anymore.
With this shift in write strategy, snapshots instantly become as effortless as a free giveaway. A snapshot is nothing more than saving a state of the file system at a given moment so you can jump back anytime later. Traditional approaches either physically copy the data or rely on LVM at the bottom level to nervously reserve space and carve out volumes. Creating a snapshot in Btrfs only requires creating a new index entry pointing to existing data blocks—not a single byte of physical data on disk needs to move. In the words of the official documentation: the snapshot is instantaneous and only creates a new tree root copy.
Along with this write action, corrupted data is exposed on the spot. Before any data block lands on disk, a checksum is calculated—like stamping a seal onto the content. When reading data, it calculates the value again; if the numbers don’t match, it immediately throws an error. The old ext family lacked this mechanism, so when a disk quietly returned corrupted data, the system would accept it without noticing and even package it right into backup files. With the seal in place, dirty data can forget about sneaking into the backup chain. However, repairing a corrupted block requires having another intact copy in hand; in a single-disk setup with only one copy, the checksum mechanism is responsible for yelling out the problem loudly, while repair must wait until a redundant copy is available.
Moving disks online also comes naturally. Its index structure built-in back-references, so the file system always knows exactly which physical disk every data block is sitting on. When you want to add disks, remove disks, expand, or shrink partitions during day-to-day operations, you can just execute it online without messing around with three layers of tools doing a painful relay.
The elegance lies in the fact that snapshots, checksums, compression, and multi-disk management all hook onto the exact same write path. This is precisely the watershed separating it from old-school stacked solutions: stacked solutions had three sets of tools managing separate legs, whereas Btrfs manages everything in one single layer, with all capabilities flowing out from that same disk write action.
Looking back at the three stickler issues of 2007, the root cause for all of them was in-place overwrite: as soon as new content hit the disk, the old state was gone. Unable to retain old states, snapshots could only rely on outer tools copying everything first; lacking a unified point for checksums, each tool did its own thing; lacking control over allocation, multi-disk could only be wrapped in another layer outside. Btrfs changed this default behavior. Old data is not destroyed, so old state remains on disk, and snapshots just need a new entry pointing to it; all objects traverse the same write path, so attaching checksums once makes them globally effective; allocation authority is reclaimed internally, so adding and removing disks can be done online; after a sudden power loss, the ledger either stays at the old entry or switches to the new entry—theoretically avoiding half-new half-old states—so full disk checks from the ext2 era are fundamentally no longer needed. All three solutions emerged from fulfilling this single action.
Don’t mistake this trade-off for a symmetric balance of Btrfs optimizing writes and ext4 optimizing reads. The accurate accounting is: Btrfs trades read locality for on-disk history. Writes are actually faster at the moment of execution because it always picks contiguous empty spots; what suffers is reading back heavily modified large files later, whose data blocks end up scattered all over the disk. ext4 didn’t participate in this trade-off: it overwrites in place, and wherever a file lands is where it stays, paying on neither end. It has no checksums, snapshots, or built-in multi-disk, nor did it compete for those back then. This also explains why running databases on Btrfs is where it struggles the most: databases manage physical page layout themselves, while Copy-on-Write shatters that layout, which is why the performance switch +C was prepared as an exemption channel.
There is no free lunch. While trading for these benefits, the write action also signed a series of bills. Every single one is a direct consequence of this mechanism, so don’t mistake them for isolated, accidental glitches.
The first problem to knock on the door is disk fragmentation. Old data isn’t overwritten, new data settles in new locations, and frequently modified files quickly end up scattered in pieces across the disk. The official manual itself admits: In COW filesystems, files tend to fragment as they are modified. Mason himself gave an explanation (from YouTube automatic captions of his 2015 NYLUG talk): writes are actually faster because they only pick contiguous open space, but the entire cost is dumped onto subsequent reads; physical layouts meticulously planned for sequential reads by databases get turned into a jumbled mess. Virtual machine images, databases, and large files frequently rewritten in place are regular customers paying this bill.
Looking next at space management, it divides disk space into two separate ledgers. Block groups holding file entities are about 1 GiB each, while block groups holding directory structures are about 256 MiB each, accounted for independently. This gives rise to a baffling situation: even though the disk clearly shows remaining space, saving items triggers an out-of-space error, because the directory structure ledger ran out first. If you want to delete a few large files to free up space at that point, the deletion operation itself needs to write to the directory, resulting in being unable to delete files at all. This is normal logic resulting from the mechanism, which is why official documentation to this day recommends keeping a 10 GB buffer per volume and limiting snapshots to under 12.
Behavior after a power failure can be equally tricky. Copy-on-Write guarantees ledger integrity provided the physical disk strictly respects write ordering. An unscrambled ledger doesn’t mean booting up will go smoothly: if something goes awry in the index tree, bootup fails to mount directly and drops into a recovery shell, requiring specialized commands to repair. Normally, people rarely touch recovery environments, so encountering one leaves them bewildered. A concentrated wave of users hit a pitfall in the summer of 2025, where a long-lurking bug became very easy to trigger in kernel 6.15.3, locking up power-cycle reboots during log replay. Maintainers confirmed the issue, scheduled mainline fixes for 6.17, and Fedora closed the corresponding ticket in its 6.15.9 patch set. The way such problems present themselves to users is bizarre enough: hardware and performance look completely fine, but you just can’t log into the system.
Performance tuning flags are another subtle trap. Applying the +C attribute to database or virtual machine files disables Copy-on-Write, instantly restoring random write performance. The official documentation explicitly notes: adding this flag causes the system to simultaneously disable data checksums for those files. Mind you, to chase performance, people strip off the seal they just traded for on the exact large files that fear silent corruption the most. systemd adds +C to the system journal directory by default, and virtualized component libvirt frequently adds it to VM images, while plenty of users remain completely unaware.
As for the debt incurred by multi-disk arrays, it involves even more and deserves to be pulled out for detailed discussion. The pitfalls there haven’t been filled to this day.
Once volume management and file system merged, Btrfs logically gained authority over multiple disks. Mirroring two disks leaves a complete copy on each side; if a bad block is read on one side, data is pulled from the other to repair it, completing the self-healing loop for checksums here. Multiple disks can also slice and stripe data to boost read/write throughput. Yet its ambition went beyond this: it also wanted to incorporate RAID5/6, using parity so data could be recalculated from remaining drives if one failed. Unfortunately, this hard nut hasn’t been cracked smoothly to this day.
Flipping open the official status page (corresponding to kernel 7.1), the RAID5/6 section still prominently says unstable, and the manual states plainly should not be used in production. At the core of the problem is the old flaw known as the write hole. Upon an unexpected power loss, a stripe of data might end up half written with old data and half with new data, leaving no one able to tell which half the underlying parity code is anchored to. When the system reboots, it might very well take corrupted dirty data as the reference standard and turn around to overwrite and ruin intact data during repair. To plug this hole, you either introduce a write log or faithfully perform full read-modify-writes every time. Back then, full read-modify-write was rejected due to terrible performance, while the write-logging mechanism was never delivered. Caught empty-handed on both ends, the vulnerability has remained to this day.
The post-mortem on 6.2 in the official kernel release history puts it frankly: chopping off the read-modify-write step back then to chase performance became the source of all future reliability hazards. The 6.2 kernel released in 2023 merged some patches, but RAID6 still has a lot of work pending; the new stripe tree architecture has entered experimental branches, with official statements believing this route will ultimately resolve existing issues. This technical debt incurred early in the design is still being paid off in installments today.
Counting from when it merged into mainline Linux in 2009, the path Btrfs has traveled over these dozen-plus years is practically one long catch-up checklist. The issue of throwing errors when disk space filled up during power outages only wrapped up its first round of fixes in 2010; the free-space caching mechanism produced its first version in 2011, was torn down and rewritten into B-trees in 2016, and wasn’t promoted to default until 2021, while the earliest implementation wasn’t officially marked deprecated until 2024. As relayed by dual sources, the physical disk format was declared stable in November 2013, and partitions created since then can be mounted directly by subsequent newer kernels. In 2023, it was fixing multi-disk read-modify-write logic, and in 2025, it was still investigating log replay glitches in 6.15.3.
Looking at this timeline also makes it clear why its early reputation was so bad. Around 2011, forum posts frequently surfaced with laptop users losing entire drives of data or being unable to write despite having plenty of free space. Most of these storms were concentrated around the years before and after the physical format freeze. In 2017, Red Hat announced it was blocking Btrfs from full support, and by RHEL 8 removed it entirely—the official explanation being that Technology Preview features were never intended for full support, without mentioning data loss once. Those awful early experiences certainly existed, but the old code corresponding to those painful histories is separated from the version running on your machine today by over a decade of intensive patching.
To gauge the right selection criteria, you still have to go back to that write action. Its strengths and shortcomings are two sides of the same coin: whether it fits depends entirely on whether your daily needs happen to leverage its features or run headfirst into its bills.
The top recommendation where its strengths shine—and where you can pick it without a second thought—is a single system disk. Two major distros have backed it with default configurations for years: the SUSE family sets the system disk to Btrfs by default, paired with automated snapshots so if a system update goes south, you can just pick yesterday’s image at boot to roll back—an out-of-the-box complete experience. Fedora Workstation also uses Btrfs by default, though the official docs state clearly that the system doesn’t include automatic snapshot rollback out of the box, requiring manual tool setup if desired. Default choices by distributions often speak volumes. For machines where people frequently tweak kernels and drivers or perform major version upgrades, snapshot rollbacks save a ton of time. Mirroring two disks is equally worry-free; official rating marks it OK, where corrupted blocks can be automatically healed from the mirror, completing the self-healing loop.
You also need to keep in mind scenarios prone to landmines where steering clear is advised. If you want to set up a RAID5/6 array, reliably construct it with traditional low-level array tools and format the upper layer directly with a standard file system, avoiding native Btrfs arrays. Directories hosting databases and VM images must either endure fragmentation silently or have the +C attribute added manually; as a quick reminder, after adding +C, these files lose checksum protection. Running container services also doesn’t require fussing with storage drivers—the official documentation states that even on Btrfs, overlay2 is still recommended. If you don’t want to spend mental effort understanding the two space ledgers, be mindful in daily use: remaining capacity readings can easily mislead, and snapshots will quietly consume the entire disk in the background.
Finally, a couple of honest words on technical boundaries. A snapshot is not a backup: snapshots and original data share the same underlying storage blocks, so if physical hardware fails, both suffer together—closed out by a single sentence in official docs: A snapshot is not a backup. Checksums can indeed catch corrupted data quietly returned by a drive and recover it when extra copies exist, but they can’t save a broken drive that can’t be read due to hardware failure, nor can they replace off-site disaster recovery. Spotting an error and fixing the data are two completely different things.
Grasping this trade-off behind low-level disk writes is far more useful than memorizing any feature list. Whenever Btrfs introduces new features or exposes new risks down the road, following this core action allows you to deduce the underlying reasons right away. This way of thinking works just as well for other low-level software: pin down its most fundamental core action, see what capabilities it acquired and what costs it incurred, and every design trade-off that follows will naturally become crystal clear.