Linux 6.16 and the steady grind of filesystem work

Linux 6.16 shipped this week. There is no headline feature, which is worth writing about, because a project that ships boring releases on schedule is a healthy one.

the notable bits#

ext4 gains support for concurrent direct I/O writes to the same file when using extent-based allocation without needing exclusive inode locking. For database workloads on ext4 this is a meaningful throughput improvement — the exclusive lock was a real serialization point on write-heavy workloads with many threads hitting one large file.

If you run Postgres or MySQL on ext4 with direct I/O, this is worth benchmarking after you upgrade.

Btrfs continues its steady improvement, including better handling of large folios. XFS got more work on its atomic write support, which is one of those capabilities that unlocks meaningful optimizations in databases that can rely on it — no more double-write buffers if the filesystem can guarantee torn-write protection.

More Rust bindings landed, including additional infrastructure for DRM drivers. The Rust-for-Linux effort continues its subsystem-by-subsystem advance.

Futex improvements for scalability under contention, which matters for any heavily threaded userspace runtime — the JVM, Go's scheduler, and every async runtime with a work-stealing thread pool ultimately bottom out here.

the thing about boring releases#

The Linux kernel ships roughly every nine to ten weeks. It has done so for two decades. Every release contains thousands of commits from over a thousand developers across hundreds of companies who mostly compete with each other.

There is no roadmap document. There is no product manager. There is a maintainer hierarchy, a merge window, a stabilization period, and a release.

It works better than almost any commercially-managed software project on earth, and the reason is worth thinking about: the process optimizes for not regressing above everything else. The famous "we do not break userspace" rule is not politeness, it is the constraint that makes an enormous decentralized project tractable. If the interface contract is inviolable, subsystems can evolve independently without coordination.

That is the actual lesson for people building large systems. Stable interfaces between components are what let you have many independent teams. Every organization that struggles with cross-team coordination is, underneath, struggling with unstable interfaces.

the maintainer question#

Worth noting alongside: the kernel has a succession problem. A meaningful number of critical subsystems are maintained by people who have been doing it for fifteen or twenty years, and the pipeline of replacements is thin.

This is true of most critical infrastructure software and it does not get attention because it is not an incident until it is. The number of load-bearing open source projects with exactly one active maintainer remains one of the scariest statistics in computing.

If your company depends on the kernel — and it does — funding maintainers is a better use of security budget than most of the things in your security budget.