19 October 2026Maple Circuit · File systemsCurated

Linux 7.3: what changes in btrfs

Summary

In its video on Linux 7.3, released on 18 October 2026, the YouTube channel Maple Circuit focuses on the changes to the btrfs file system. According to David Sterba's pull request, the release brings noticeable performance gains for direct I/O, copy-on-write and fsync, plus changed mount options that admins should know about before updating. This post explains the changes based on the patches on the mailing list and puts the quoted measurements into context.

Linux Kernel 7.3 | BTRFS IS SOOO BACK!Maple Circuit · 1:16:23Play video, loads the YouTube player

The player from youtube-nocookie.com only loads after you click; Google then receives your IP address, among other data. Without JavaScript, the click opens the video on YouTube. Privacy

What admins should check before updating

The old free space cache (space cache v1) is disabled by default as of Linux 7.3. Since btrfs-progs 5.15, mkfs.btrfs creates its successor, the free space tree (v2), anyway. According to the pull request, file systems with v1 keep working but may be slightly slower because block group caching is missing.

The rescue option rescue=usebackuproot, which falls back to an older copy of the tree root when mounting, now requires a read-only mount; the developers consider a writable mount too risky. The standalone option usebackuproot, deprecated since kernel 5.9, has been removed. If it is still present in /etc/fstab or the kernel parameters, it should be removed before updating.

Direct I/O without falling back to the page cache

Databases and other programs that do their own buffering often use direct I/O to bypass the kernel's page cache. Until now, btrfs fell back to buffered writes in certain cases, a concession to correctness at the expense of speed. As of 7.3, btrfs copies the data into a bounce buffer of the iomap layer instead. According to the pull request, this raises performance from about 50 to about 95 percent of the theoretical maximum.

Less repeated copying with copy-on-write

btrfs never modifies metadata blocks in place but writes a copy (copy-on-write). If background writeback writes out a block that a running transaction is still working on, btrfs has to copy it again; this extra work is called COW amplification. Since an earlier change, btrfs therefore temporarily exempts such blocks from writeback. However, the XArray used for this cost 22.6 percent of write performance according to the kernel test robot, and when deleting large, heavily fragmented files the cleanup at the end of the transaction could block for seconds.

Leo Martins replaced the XArray with a fixed buffer of eight slots managed by a CLOCK eviction policy. Blocks that the transaction touches again get a second chance; blocks used only once are evicted first. In the test, there were 6.1 repeated copies per first copy without protection, 1.6 with the new buffer and 1.4 with the old XArray. Almost all of the protection remains, without the performance loss.

Faster fsync via the log tree

To make fsync fast, btrfs does not write the whole transaction but only the necessary metadata into a separate log tree, which is replayed after a crash. When several processes were logging at the same time, btrfs waited for one jiffy on drives it does not classify as SSDs, or with the nossd mount option; a jiffy is one tick of the kernel timer, 1 to 10 milliseconds depending on CONFIG_HZ. The pause was meant to batch further commits. Filipe Manana removed it; according to the pull request, latency drops and throughput rises to about five times on the sample workload.

A second patch by Filipe Manana concerns full fsync runs. With the no-holes feature, the default since btrfs-progs 5.15, btrfs no longer stores holes in files as separate items, so a full fsync searched all extents of a file for holes. As of 7.3, the search is skipped if the file has no preallocated extents and the space used is at least the file size. In the test script with 65,536 extents, the time dropped from 28.7 to 5.5 milliseconds.

Ideas

Before every kernel update, check removed mount options against your own fstab.
Use rescue options read-only, not in normal operation.
A small list with good eviction almost replaces an unbounded data structure.
Artificial waits for batching can cost more than the batching gains.
Comparing file size with space used saves the search for holes.
Automated test runs like the kernel test robot catch performance regressions early.

Insights

Some of the large factors only recover losses from earlier fixes: first the protection against COW amplification cost performance, now it returns with a leaner data structure. Anyone comparing kernel versions needs to know which baseline is being measured.
Many gains come from shortcuts for common cases: no hole search when no hole is possible, no waiting when nothing gets batched anyway. Such shortcuts are only as good as the check of their condition.
The video explains the patches clearly, but the reliable measurements and their limits are in the commit messages on the mailing list.

Facts

Linus Torvalds released Linux 7.3 on 18 October 2026.
David Sterba sent the btrfs changes for 7.3 to Linus Torvalds on 19 August 2026.
The new buffer against COW amplification has eight slots (BTRFS_INHIBITED_EBS_SLOTS).
With the XArray, the kernel test robot measured 22.6 percent fewer write IOPS for random 4k writes.
The free space tree (v2) has been the mkfs.btrfs default since btrfs-progs 5.15.

References

Critique

The title and introduction of the video overstate things: it speaks of one of the biggest performance jumps it has ever seen from one release to the next, but part of it only recovers losses from earlier fixes. According to the pull request, the new buffer merely restores the state before the protection against COW amplification; the video says so itself at that point, the title “BTRFS IS SOOO BACK!” does not.
The factors around 5 come from sample workloads; the fsync test ran on a simulated null block device (/dev/nullb0) and measures milliseconds. They say little about real drives in everyday use, and the video itself reports results within the margin of error for many benchmarks.

Remarks

The video attributes the earlier direct I/O fallback to misaligned writes; the pull request speaks more generally of past trade-offs between correctness and speed.
The largest benchmark gain in the video, a 3.8 times lower latency for the financial database TigerBeetle, comes from a Phoronix test that could not be verified for this post.

Recommendations

Before updating, search for the removed option with grep usebackuproot /etc/fstab /etc/default/grub /proc/cmdline and delete it.
Use btrfs inspect-internal dump-super <device> to check whether FREE_SPACE_TREE appears in the compat_ro flags; if not, v1 is still in use, and mounting once with space_cache=v2 converts it.
Measure databases and machines with hard disks and many fsync calls yourself after the update instead of relying on the factors from the patches.
For details, read the commit messages on lore.kernel.org; they contain test scripts and limitations.

Watch the video

Search the Web Archive