Linux Kernel to Curb Proliferation of File Systems with New Guidelines for Acceptance

Maintenance Limits: The Proliferation of File Systems and the Burden on VFS Developers

The extensibility of the Linux kernel is characterized by its diverse support for file systems (FS). However, this diversity has increasingly become a “burden” for developers. According to a report by Phoronix, the mainline kernel in its current development phase for Linux v7.1 contains around 69 types of file systems. These range from general-purpose FSs like EXT4, Btrfs, F2FS, and XFS, to network FSs like NFS, pseudo-FSs like proc, specialized FSs like ZoneFS, and even older remnants like BeFS and JFS.

For the developers managing the virtual file system (VFS) layer that supports this vast array of file systems, maintenance has become an increasingly challenging issue. In particular, the presence of outdated file systems that are no longer maintained or are difficult to test poses a significant obstacle to the evolution of VFS code.

”Expand, Use FUSE”: New Guidelines for Upstreaming File Systems

In response to this challenge, VFS maintainers have taken action. The immediate trigger was the proposal of two new file systems, FTRFS and VMUFAT, which raised concerns about the “ongoing maintenance burden” they would impose. Consequently, a documentation patch outlining clear guidelines for the upstreaming (integration into the mainline) of new file systems has emerged in the “vfs-7.2.misc” development tree for the Linux 7.2 merge window.

At the core of these new standards is the principle: “Prioritize extending existing file systems.” Even for niche use cases, developers are encouraged to explore adding functionality to existing file systems first. If this proves unfeasible, the use of user-space file systems (FUSE) is recommended. This approach highlights a cautious stance toward introducing new code into the kernel space.

Technical Requirements and Maintenance Commitments

The new guidelines establish criteria from both technical and developer commitment perspectives. Technically, any new file systems must avoid reliance on deprecated code and utilize modern VFS interfaces. Developers are also required to provide user utilities (such as formatting tools) and integrity checking tools to support the functionality of their file systems. Comprehensive testing and proper documentation are also deemed essential.

Most importantly, the new guidelines emphasize the necessity of a strong maintenance commitment. The document states that if maintainers become unresponsive, fail to adapt to changes in kernel infrastructure, or cease testing, the file system in question may be deprecated and ultimately removed from the kernel. This reflects the development community’s firm stance: “If you add something, you are responsible for maintaining it.”

Impact: Balancing Quality and Innovation

This initiative represents a crucial step toward ensuring the health of Linux kernel development. By curbing the unchecked proliferation of file systems and conserving the valuable resources of VFS developers, the move is expected to enhance the stability and maintainability of the kernel as a whole. However, concerns remain that these stricter guidelines could raise the barrier for developing innovative new file systems. How these guidelines are implemented will significantly shape the future evolution of the Linux kernel.

---

FAQ

Q: Why does the Linux kernel support so many file systems?
A: Linux supports a wide variety of file systems to cater to diverse hardware and use cases, including embedded systems, servers, desktops, and specialized applications. Additionally, as an open-source platform, Linux has historically incorporated file systems developed by research institutions and companies. While this diversity is a strength, it also poses challenges for maintenance.

Q: What does the guideline to “extend existing file systems” specifically mean?
A: For example, if there is a demand for a new feature such as faster file copying, developers are encouraged to implement this feature as a patch to an existing file system like EXT4 or Btrfs, rather than creating an entirely new file system from scratch. This approach leverages existing codebases and toolchains, significantly reducing maintenance costs. The new guidelines strongly advocate for such a development approach.

Q: Will file systems become immediately deleted if their maintainers stop responding?
A: Not immediately. The guidelines suggest that a deprecation process will be followed first. During this time, the community may explore alternative solutions or recruit new maintainers. However, file systems that remain untested and unmaintained for extended periods may ultimately be removed to preserve the kernel’s overall quality. This is a last-resort measure to ensure the long-term health of the kernel.