Linux tightens rules for new file systems

Linux maintainers accepted new guidance for file systems that seek mainline kernel support, according to Phoronix. The document, Documentation/filesystems/adding-new-filesystems.rst, gives developers a clearer test before they ask VFS maintainers to carry another storage stack.

{{IMAGE:2}}

The rule set targets a common kernel maintenance problem: developers propose a file system, gain early attention, then leave VFS maintainers with code that few users run and fewer developers test. The new guidance asks maintainers of proposed file systems to prove two things: the design solves a problem existing file systems cannot cover, and the team can support the code after merge.

For builders, the practical effect lands in compatibility and operations. A file system that reaches mainline affects installers, initramfs tooling, backup software, rescue media, container runtimes and bootloaders. If its mkfs or fsck tools lag behind the kernel code, users pay the cost during upgrades and recovery.

Area	New expectation	Builder impact
VFS interfaces	Developers must use current kernel APIs	Less old code for VFS maintainers to preserve
User-space tools	Projects need mkfs, fsck and documentation	Admins can create and repair volumes without custom steps
Testing	Maintainers need test coverage that others can run	Regressions have a better chance of surfacing before release
Uniqueness	Developers must explain why ext4, XFS, Btrfs, F2FS or FUSE cannot cover the use case	Fewer niche in-kernel formats with small user bases

The guidance also pushes niche projects toward FUSE. That choice makes sense for prototypes, research formats and narrow appliance use. FUSE keeps experimental code out of the kernel, while users can still mount and test the format from user space.

Performance claims will need more discipline under this model. A serious file system submission should include fio results, metadata stress tests, fsx coverage and crash-consistency checks across kernel versions. Power data also matters on laptops and dense storage nodes: a format that wins throughput but keeps CPUs awake can lose in a 24-bay NAS or small homelab box.

Test class	Useful metric	Why it matters
Sequential I/O	Read and write throughput at queue depths one and 32	Shows disk and NVMe scaling behavior
Small-file metadata	Creates, deletes and renames per second	Exposes pain in package installs and source trees
Crash recovery	Mount and repair time after fault injection	Measures admin downtime after power loss
Idle behavior	Package power and wakeups per second	Shows cost on laptops and low-power servers

Linux already carries mature choices for most builds. Use ext4 for broad compatibility, XFS for large files and steady server workloads, Btrfs for snapshots and checksumming, and F2FS for flash-focused systems. A new in-kernel file system now needs to beat those choices in a defined role, then keep proving it through tests and maintenance.

Developers can follow the kernel tree through kernel.org and the upstream source at git.kernel.org. Phoronix covered the merge in its Linux storage report: Linux enacts guidance to tighten acceptance of new file-systems into the kernel.