Btrfs Change Coming For Linux 7.2 Yields Very Healthy Performance Gain
#Infrastructure

Btrfs Change Coming For Linux 7.2 Yields Very Healthy Performance Gain

Chips Reporter
3 min read

A significant performance improvement for Btrfs direct I/O writes is coming in Linux 7.2, fixing a regression that mistakenly serialized DIO operations since 2023, resulting in up to 59% throughput improvement.

A change coming in the Linux 7.2 kernel cycle is delivering a substantial performance boost to Btrfs direct I/O operations. The fix addresses a regression introduced during Btrfs's transition to the new mount API in 2023, which mistakenly forced direct I/O writes to be serialized. This oversight has now been corrected, yielding performance improvements ranging from 12% to nearly 60% depending on the hardware configuration.

The technical issue centers around the SB_NOSEC flag, which tells the Virtual File System (VFS) that a filesystem may have files without security extended attributes (xattrs). This flag enables certain optimizations in the kernel. During the migration to the new mount API, this flag was inadvertently omitted from Btrfs's implementation, causing IS_NOSEC to always return false for Btrfs inodes.

When IS_NOSEC returns false, the btrfs_direct_write() function acquires the inode lock exclusively, forcing direct I/O writes to the same file to be serialized rather than executed concurrently. This serialization creates a bottleneck that significantly limits throughput for applications that perform direct I/O operations.

Mark Harmstone with Meta discovered this issue and implemented a straightforward fix by restoring the SB_NOSEC flag in Btrfs's mount implementation. According to Harmstone, "Before btrfs switched to the new mount API in 2023, we were setting SB_NOSEC in btrfs_mount_root(). This flag tells the VFS that the filesystem may have files which don't have security xattrs, enabling it to do some optimizations. Unfortunately this was missed in the transition, meaning that IS_NOSEC will always return false for a btrfs inode. This means that btrfs_direct_write() calls will always get the inode lock exclusively, meaning that DIO writes to the same file will be serialized."

The performance impact is substantial. On Harmstone's test machine, the change resulted in a 59% improvement in direct I/O throughput, increasing from 826 MB/s to 1311 MB/s. Intel's Kernel Test Robot has independently verified this improvement, reporting approximately 12% better Btrfs performance with this change in their testing environment.

Direct I/O is an important operation for many applications, particularly database systems, virtualization platforms, and high-performance computing workloads that bypass the page cache to interact directly with storage devices. By allowing these operations to proceed concurrently rather than being serialized, the fix enables better utilization of modern storage hardware, especially NVMe devices that can handle multiple I/O operations in parallel.

The patch has been merged into the Linux kernel's "-next" tree, indicating it's on track for inclusion in the Linux 7.2 release. The merge window for Linux 7.2 is scheduled for June 2026, meaning users can expect to see this performance improvement in the stable kernel release shortly thereafter.

This fix represents an important optimization for Btrfs, which has gained popularity as a default filesystem for many Linux distributions due to its advanced features including snapshots, checksums, and efficient storage management. The performance improvement comes without any changes to the on-disk format, making it a safe update for existing Btrfs filesystems.

For organizations running Btrfs in production environments, particularly those with workloads that involve heavy direct I/O operations, this change should provide noticeable performance improvements with no additional configuration required. The fix demonstrates the value of thorough kernel development practices and the importance of maintaining filesystem-specific optimizations during API transitions.

Comments

Loading comments...