The Btrfs pull request for Linux 7.3 reports several substantial improvements, but each belongs to a particular path or workload. It also changes free-space caching and recovery mounts, which deserve attention independently of speed.
Four results with different denominators
David Sterba’s August 19 pull request describes direct I/O using an iomap bounce buffer where it previously fell back to buffered I/O. Reported throughput rises from roughly 50% to 95% of the theoretical maximum for the affected case. That is about 1.9 times the throughput, not a 95% improvement in every Btrfs operation.
The other results concern inhibited extent-buffer tracking, removal of a one-jiffy delay during concurrent logging on non-SSD mounts, and skipping hole detection during full fsync on files without holes but with many extents. The respective reported improvements are around 3×, 5× throughput and 5× shorter runtime in their stated workloads. The fsync example operates in the microsecond range.
Those numbers are developer results, not PeopleAreGeek measurements. Multiplying them together would combine different operations into a benchmark nobody performed.
Translate a rate into elapsed time
An original arithmetic example helps interpret the direct-I/O figure. Assume a theoretical ceiling of 1,000 MB/s and a fixed 1,000 MB transfer with no other work. At 50% of the ceiling, the transfer takes two seconds. At 95%, it takes approximately 1.05 seconds: about 47% less time.
If an application also spends three unchanged seconds computing, its total falls from five seconds to about 4.05 seconds, a 19% reduction. These invented round numbers illustrate why a storage-path improvement does not predict an application's overall speedup. The cover shows this distinction.
Review cache and recovery settings separately
The pull request disables the v1 free-space cache by default. It explicitly says existing v1 filesystems still work, potentially more slowly because block-group caching is unavailable. An absent free-space-tree flag alone does not prove that v1 caching is actively enabled: caching can also be disabled.
The mount-option documentation explains v2 activation and cache clearing. Enabling v2 clears v1 at the first mount; the original article’s mandatory extra offline clearing step was misleading. Check the actual filesystem, mount options and older recovery-kernel compatibility before planning a conversion.
Also review recovery scripts: the standalone usebackuproot option is removed, and rescue=usebackuproot requires a read-only mount. A performance upgrade is not a reason to alter recovery options casually. For evaluation, preserve the current workload and measure its actual I/O path, latency and correctness on a test volume before comparing results.
Separate four workload-specific results, explain throughput versus duration, correct v1 cache migration and rescue mount implications.