Linux 7.3 Made BTRFS Up to 5.7x Faster, and It Did It by Deleting Code. Here Is How

Most kernel releases are a long list of small things. Linux 7.3 has a theme, and that theme is speed won by taking code out. BTRFS, the copy on write filesystem a lot of people still write off as slow, picked up performance gains between about 3x and 5.7x on specific workloads, and the pattern behind them is almost always the same. A safety mechanism was doing far more work than the situation needed, and a developer replaced it with something lighter. I want to walk through the real changes, with the numbers from the patches themselves, because this release is a clean lesson in where filesystem time actually goes.

The 5.7x win came from deleting a 1 millisecond nap

Start with the single most dramatic number. BTRFS uses something called a log tree to make fsync fast. When a program calls fsync, it is asking the system to guarantee that a file is safely on disk before continuing, and the log tree lets BTRFS promise that without writing out a full transaction every time.

On spinning disks, BTRFS used to pause for 1 jiffy before committing the log. A jiffy is the kernel’s basic timer tick, usually somewhere between 1 and 10 milliseconds depending on configuration. The idea was reasonable on paper. If several tasks were logging at once, waiting a moment let the system bundle their writes together, which is kinder to a hard drive that hates lots of tiny requests. The problem is that the wait itself became the bottleneck. 10 milliseconds is an eternity next to everything else in that path, and when multiple tasks were logging, that forced nap turned concurrent work into a single file queue.

Filipe Manana, the BTRFS developer who did most of the heavy lifting this release, stripped the sleep out entirely. The result, measured with a fio random write test doing fsync on every write, went from 2,647 KiB per second to 14.9 MiB per second. That is about 5.7x faster, and all it took was removing the code that told the system to wait.

Figure 1. Removing a 1 jiffy sleep from the BTRFS log commit path took a fio fsync workload from 2,647 KiB/s to 14.9 MiB/s, about 5.7x faster. Source: Filipe Manana BTRFS patch set, Linux 7.3

Skipping work you can prove is unnecessary

The second BTRFS win follows the same logic. When BTRFS runs a full fsync, it checks for holes in the file. A hole is a gap you create when you skip ahead in a file before writing, and the log tree has to know a hole exists, because without that record a crash recovery would read whatever random bytes sit underneath and treat them as real data.

Detecting holes means scanning every extent in the file to confirm there are no gaps. On a small file that is nothing. On a heavily fragmented 10 GB file that might hold 20,000 extents, scanning all of them on every fsync is brutal, and for most files it is wasted effort because the file has no holes at all. The fix is a short piece of math that proves a file cannot have a hole without walking its extents. If the no holes option is on, preallocation is off, and the logical size of the file is less than or equal to the bytes actually allocated on disk, there is no room for a hole to hide, so the scan gets skipped. On fragmented files, that change produced roughly a 5x speedup, again by doing less.

Direct IO got the same treatment. BTRFS now uses an iomap bounce buffer when a direct IO request is misaligned, correcting it in a small buffer in place, where before it would give up and fall back to the slow buffered IO path through the page cache. That one change moved direct IO performance from about 50% of the theoretical limit to about 95%.

There is a fourth BTRFS change in the same spirit, and it is the one that fills out the low end of that 3x range. Copy on write filesystems have a habit of rewriting metadata when a write lands out of order, a problem called cow amplification, and an earlier release used an xarray to track in progress metadata buffers and prevent it. Maintaining that xarray turned out to be heavier than the problem it solved. Replacing it with a small local LRU list, a lighter structure holding a handful of buffers, restored performance to its pre fix level while still preventing the amplification, worth about 3x on the affected path. 7.3 also flips the BTRFS free space cache to version 2 by default, retiring the older v1 format.

Figure 2. 4 BTRFS changes, 4 speedups, all from removing or avoiding work. Log commit sleep removal, fsync hole detection skipping, a lighter extent buffer tracker, and direct IO via a bounce buffer. Source: Linux 7.3 BTRFS changes, Phoronix and patch data

The memory allocator stopped making cores fight

Away from filesystems, 2 memory management changes landed that matter for anyone using compressed swap, which is to say most modern desktops and plenty of servers running ZRAM or zswap. Both are about lock contention, the situation where many CPU cores stall waiting for the same lock.

The first touches zsmalloc, the allocator behind ZRAM and zswap. Freeing compressed memory used to require grabbing a pool wide lock just to look up which size class a chunk belonged to, and that pool is shared across the whole system for zswap. Under memory pressure, every core trying to free memory would pile onto that one lock. Wenchao Hao of Xiaomi added the size class directly to the object so the lookup no longer needs the lock. On a Raspberry Pi 4B the whole page out and free sequence ran up to 1.83x faster, with a smaller gain on a 20 core Intel box.

The second is kernel samepage merging, or KSM, the feature that scans memory, finds identical pages, and merges them to save RAM. On a database server that carves its memory into tens of thousands of small regions, KSM’s reverse mapping walk was treating every region as a candidate for a single target page, which meant huge scans. Xu Xin of ZTE passed a precomputed page index into that walk so it jumps straight to the right candidate using an existing interval tree. In a test with 20,000 regions sharing 1 structure, the lock hold time dropped from 705 milliseconds to about 1.44 milliseconds. Half a second of freezing, gone.

Figure 3. The KSM reverse mapping fix cut the anon_vma lock hold time from 705 milliseconds to about 1.44 milliseconds in a 20,000 region test, ending multi hundred millisecond stalls. Source: Linux 7.3 memory management, via LWN

Letting a core walk away from an interrupt

There is a matching story in how cores coordinate. When the kernel needs every core to do something, like flushing a translation lookaside buffer on x86, it sends an interprocessor interrupt, an IPI, and waits for the target cores to finish. The core that sent the IPI could not be preempted while it waited, because the list tracking which cores were done was a single shared buffer that had to be protected.

So if core 1 waited on core 2, and core 2 was itself stuck waiting on another IPI, you could end up with a chain where the whole machine stalled on 1 core. ByteDance engineers gave each task its own IPI tracking mask, replacing the single shared one per core, which removes the need to block preemption during the wait. In a benchmark measuring how fast a high priority task can start running after an IPI, latency fell from 17 milliseconds to 1.5 milliseconds, roughly a 90% reduction. That is the kind of number that matters for audio, for real time control, and for anything that cannot tolerate a scheduler hiccup.

A filesystem whose only job is to fail

Not every change in 7.3 is a benchmark. Christian Brauner, who maintains the virtual filesystem layer, shipped a new pseudo filesystem called failfs, and it does exactly 1 thing. It fails. Ask for its parent directory, fail. Try to access the root, fail. Try to mount it, clone it, or run a binary inside it, every one of those returns operation not supported.

The point is the strongest sandbox possible. Containers restrict what a process can reach, but until now there was no way to fully remove storage from a container. failfs, paired with a new fchroot system call that chroots into a file descriptor, lets you drop a process into a void where the only path to the outside world is a file descriptor you explicitly hand it. If a process cannot even find the filesystem, there is nothing there to exploit. The name makes it sound like a gag, but it gives containers a way to hand a process a storage environment with nothing in it at all.

A cleaner way to write without filling the cache

Databases have a long running fight with the kernel’s page cache. The page cache keeps recently touched data in memory to speed up future reads, which is great until your program manages its own cache better than the kernel can, at which point the page cache is just wasting RAM on data the program will never reread. There is a per IO flag, RWF_DONTCACHE, that says write this through but do not keep it around, and 7.3 extends it to raw block devices, where before it only worked on files. Tal Zussman enabled it, which helps databases like the ones that talk straight to a block device with no filesystem in between.

Getting there surfaced a problem that kept showing up across the kernel. Dropping a page from the cache requires a lock, and acquiring that lock can put the task to sleep, but the completion of a disk write runs in interrupt context, where sleeping is forbidden. Different subsystems had each invented their own workaround, pushing the cleanup onto a separate work queue. 7.3 adds a shared solution, a flag on the block layer’s basic unit of work that defers the completion to normal task context when needed. Once it existed, it got adopted everywhere the same pattern appeared, in zswap writeback, in F2FS, in XFS, in the iomap layer. One helper replaced a half dozen copies of the same careful hack.

Everything else worth knowing

A few more changes round out the release. EXT4 got a faster iomap based direct IO path for simple requests, which pushed a sample workload from 1.92 million to 2.19 million IOPS. The base M3 Apple Silicon support from 7.2 expanded to cover the M3 Pro, Max, and Ultra, which is early boot scaffolding and not yet daily driver support, with the Asahi Linux team still ahead of mainline for anyone actually running Linux on Apple hardware. On the GPU side, work landed to keep games from crashing when they need more VRAM than the card has, tested on Indiana Jones and the Great Circle running in 9 GB on an 8 GB GPU at a usable frame time.

The release also deleted a pile of dead code, including a 3G PCMCIA card driver last mentioned on a forum in 2011, a readonly SGI filesystem unmaintained for over 20 years, and the Veritas filesystem that once let Linux read old Unix partitions. Less unmaintained code means a smaller attack surface and fewer drags on the subsystems that have to keep working around it. Andrew Morton, who maintains memory management, also started using AI to draft the plain English summaries at the top of his pull requests, with a human still reviewing every one, which is about the lowest risk place in the kernel to let a model help.

The release itself is getting bigger, and AI is part of why

7.3 is also a data point about how the kernel is being built now. It landed on 18 October 2026 with 15,267 commits in the merge window, the second busiest in the project’s history, behind only 7.0. The codebase crossed roughly 40.98 million lines, up from 40.42 million in 7.2, and a single release candidate added around 560,000 lines, a large chunk of it AMD display headers.

Figure 4. Linux 7.3 shipped 15,267 commits, the second busiest merge window ever, and pushed the codebase to about 40.98 million lines. Source: Linux 7.3 release reporting

Linus Torvalds has tied some of that growth directly to AI. LLM coding agents are finding bugs and helping write fixes, and the same tooling is speeding up the removal of old, unmaintained drivers, which is part of why 7.3 could delete so much dead code at once. Torvalds has said publicly that he uses Claude Code himself to make code more readable and to surface extra bugs. The community is now working out formal guidelines for AI assisted contributions, including a 2026 proposal from Sasha Levin of NVIDIA, and there is active debate about dropping the tag that currently marks AI generated patches. Andrew Morton, who maintains memory management, already uses a model to draft the plain English summaries at the top of his pull requests, with a human reviewing every one.

What all of this adds up to

The biggest wins in 7.3 came from developers like Filipe Manana looking at a cautious old mechanism, proving it was doing more than the job required, and taking it out. That is where a lot of filesystem and kernel performance actually hides, in the safety code written for a worst case that rarely happens. The release that found all of it is also the second largest the kernel has ever shipped, built by more people and more tooling than any before it, which is worth watching as its own story over the next few cycles.