Btrfs is getting its largest performance batch in years, and the headline is that direct I/O now reaches roughly 95 percent of theoretical maximum instead of roughly 50 percent. David Sterba of SUSE sent the file system feature updates for the Linux 7.3 merge window on Wednesday, August nineteenth, 2026. Four separate changes land wins between two and five times, and one quiet configuration change starts the retirement of the version one free space cache. If you run Btrfs on a database host, on rotational storage, or on anything that calls fsync in a loop, at least one of these will show up in your own numbers.
The short answer
David Sterba of SUSE sent the Btrfs feature updates for the Linux 7.3 merge window on Wednesday, August nineteenth, 2026. An iomap bounce buffer lifts direct I/O from roughly 50 percent of theoretical maximum to roughly 95 percent. Replacing an XArray with a local LRU list for inhibited extent buffers gives about three times. Removing a one jiffy delay in non SSD mode gives about five times on logging throughput. Skipping hole detection during full fsync on files without holes gives about another five times. The version one free space cache is now disabled by default.
File system pull requests usually read as a list of fixes with one or two percent attached. This one has four multipliers in it, and none of them come from a new on disk format.
What landed
David Sterba of SUSE sent the Btrfs feature updates for the Linux 7.3 merge window on Wednesday, August nineteenth, 2026. Four performance changes stand out, and they are independent of each other.
The first is the direct I/O path. Btrfs now uses an iomap bounce buffer rather than falling back to buffered I/O in the situations where the fallback was previously required. The pull request puts numbers on the old behaviour: a correctness versus speed tradeoff that held throughput at roughly 50 percent of the theoretical maximum, against roughly 95 percent now. That is close to a doubling, and it is the change most likely to show up on a production graph.
The second replaces an XArray with a local LRU list for tracking inhibited extent buffers. Sterba quotes around three times. This is metadata bookkeeping rather than a specific access pattern, so it is the most broadly applicable of the four.
The third removes an unnecessary one jiffy delay that applied in non SSD mode when several logging tasks ran concurrently. Latency drops and throughput rises by roughly five times on the sample workload cited. A jiffy is one kernel timer tick, so on a 250 Hz kernel that is four milliseconds and on a 1000 Hz kernel one millisecond. Small, until you multiply it by every logging task in a queue.
The fourth adds skip hole detection during a full fsync for files that contain no holes but do carry a large number of extents. That is roughly another five times, and the file shape it describes is extremely common: append heavy logs, and database files that have been rewritten in place enough times to fragment into many extents without ever becoming sparse.
Alongside those, the pull carries locking improvements across various operations, the usual bug fixes, and code quality work.
The quiet line about free space v1
Buried under the performance numbers is a configuration change worth reading twice. The v1 free space cache code is now disabled by default, in favour of the free space tree that has been the recommendation for years.
Nothing is removed and no filesystem stops mounting. What changes is the default posture. Btrfs has printed a deprecation warning to the system log when it detects v1 for some time now, and turning the code off by default is the step that normally precedes removal. Distributions that build their own kernels will decide individually whether to re-enable it, and most will not bother for long.
The practical consequence is that this is the release to audit. Dump the superblock with btrfs inspect-internal dump-super -f on the device and look for FREE_SPACE_TREE among the compat_ro flags. If it is there, you are on v2 and there is nothing to do. If it is absent, the filesystem is still on v1, and the migration is two steps: mount once with the space_cache=v2 option so the free space tree gets built, then run btrfs check --clear-space-cache v1 with the filesystem unmounted to drop the old cache.
Neither step is exotic and neither is risky, but the second one walks the whole filesystem, so it belongs in a maintenance window rather than in the middle of a Tuesday. Doing it now, on your own calendar, is considerably more pleasant than doing it later because a kernel upgrade forced the question.
Reading the multipliers honestly
Four numbers between three and five times in one pull request is unusual, and it is worth being clear about what they are not. None of them is a general claim that Btrfs is five times faster. Each attaches to a specific code path, and three of the four attach to a specific workload shape.
If your Btrfs volumes hold container images and get read sequentially, the direct I/O work will not touch you. If they sit under PostgreSQL with O_DIRECT enabled, it very much will. If your storage is rotational and Btrfs does not flag it as solid state, the logging delay removal is the one to watch. If your application fsyncs a heavily extended file on every commit, the fourth change is yours.
That specificity is a feature rather than a caveat. It means you can predict which of these applies to you before you install anything, and it means the right response is to benchmark the one path that matches your workload rather than to run a generic file system benchmark and read the average.
Two other things frame the timing. Linux 7.2 shipped in mid August 2026 with cache aware scheduling among its headline changes, so 7.3 is early in its cycle and a stable release is roughly two months away. The same merge window has already been busy on the file system side, with FailFS merged and two file systems from the 1990s dropped. Btrfs itself has had a visible run of correctness work recently, including the fixup worker restored during the 7.2 release candidates, which is a reasonable indicator that this performance work is landing on top of a codebase people are actively minding.
What to do this week
Nothing urgent, and two things worth putting on a list.
Check the free space cache version on every Btrfs filesystem you own, because that audit costs one command per device and the answer only gets more expensive to act on later. And if you have a workload that matches one of the four changed paths, capture a baseline now, while you are still on 7.2, so that the comparison you make in October is against a measurement rather than against a memory.
Sources and further reading
- Btrfs Ready With More Performance Improvements For Linux 7.3, Phoronix, August 19, 2026
- BTRFS gets a substantial performance improvement in Linux 7.3, Aptivi, August 19, 2026
- Changes by kernel version, official Btrfs documentation
- btrfs(5) mount options, including space_cache=v2, official Btrfs documentation
Frequently asked questions
What exactly changed in the Btrfs direct I/O path?
Btrfs now uses an iomap bounce buffer for direct I/O instead of falling back to buffered I/O in the cases where it previously had to. That fallback was a correctness decision rather than an oversight, and the cost of it was real. The pull request describes the old behaviour as reaching roughly 50 percent of the theoretical maximum, with the new path reaching roughly 95 percent. In practice that is close to a doubling on workloads that open files with O_DIRECT, which mostly means databases, virtual machine images and any application that manages its own cache and does not want the page cache in the way. The correctness guarantee is unchanged. Only the mechanism used to preserve it changed.
Which of these wins will I actually see on my systems?
It depends on what your workload does. The direct I/O improvement applies to O_DIRECT readers and writers, so databases and hypervisor storage. The fivefold logging throughput win comes from removing an unnecessary one jiffy delay in non SSD mode when several logging tasks run at once, so it applies to rotational disks and arrays that Btrfs does not treat as solid state. The fivefold full fsync win applies to files that have no holes but do carry a large number of extents, which is a common shape for append heavy log files and for database files that have been rewritten in place many times. The threefold extent buffer win is more general, since it touches metadata tracking rather than a specific access pattern.
What is happening to the version one free space cache?
The v1 free space cache code is now disabled by default in the kernel configuration, in favour of the free space tree, which is v2 and has been the recommended option for years. Nothing is removed yet and nothing breaks on upgrade, but the direction is unambiguous. Version one already printed a deprecation warning to the system log when detected, and disabling the code by default is the step that normally precedes removal. If you still have filesystems on v1, this is the release to migrate them, on your schedule rather than on the kernel's.
How do I check which free space cache a filesystem uses?
Run btrfs inspect-internal dump-super -f on the block device and look at the compat_ro flags. If FREE_SPACE_TREE appears there, the filesystem is already on v2 and you have nothing to do. If it does not, the filesystem is still on v1. To migrate, mount the filesystem once with the space_cache=v2 mount option, which builds the free space tree, then clear the old cache with btrfs check --clear-space-cache v1 while the filesystem is unmounted. Do the check step in a maintenance window rather than in production hours, since it walks the whole filesystem.
When will Linux 7.3 be available to me?
Linux 7.2 was released in the middle of August 2026, so 7.3 is early in its merge window right now and a stable release is roughly two months out on the normal cadence. After that, the wait depends entirely on your distribution. A rolling release will carry it within weeks. An enterprise distribution on a long term kernel will backport selectively or not at all, which for file system performance work usually means not at all. If any of these numbers matter to you commercially, the honest plan is to benchmark your own workload on a release candidate rather than to wait and hope.