Linux EFS Filesystem Deletion Debate: Maintainer Absence and Code Maintenance Limits
The Linux kernel’s EFS filesystem driver faces a curious situation: a new maintainer appeared but admits “I don’t use it.” The community debates whether to delete or keep the code.
30-Year-Old SGI IRIX Filesystem Faces Removal from Linux Kernel
An interesting debate has arisen on the Linux kernel mailing list regarding how to handle code that has long been unmaintained. The subject is the EFS filesystem driver. However, it should not be confused with AWS’s Elastic File System (EFS). This is a read-only driver for the Extent File System (EFS) used by SGI’s (Silicon Graphics) IRIX operating system, intended for handling non-ISO9660 CD-ROMs and hard disk partitions.
The discussion started when an open-source contributor submitted a patch to fix an undefined variable issue in a new version of the GCC compiler. This led to an inquiry about whether they would become the maintainer of this driver. However, the developer honestly admitted, “I don’t actually own any real EFS filesystems.” Additionally, it was pointed out that the utility for creating EFS filesystems does not work on modern Linux systems.
The 30-Year-Old Legacy: What Is EFS?
EFS is a block device filesystem used by SGI in the era before IRIX 6.0. It was used until the mid-1990s, when it was replaced by the more performant XFS. XFS was later ported from SGI to the Linux kernel and remains a widely used filesystem today.
The EFS driver still exists as source code in the current Linux kernel, but its actual user base is extremely limited. IRIX systems themselves have long faded into history, and the need to read media formatted with EFS has declined year by year.
Given this situation, the discussion on the Linux kernel mailing list is leaning toward removing the unmaintained code. A strong opinion is that users who still rely on EFS or need to recover old data can continue using older Linux kernel versions or LTS (Long-Term Support) kernels.
The Maintainer Absence Problem:
A Structural Challenge for the Linux Kernel
This incident is not just about an old filesystem. It also serves as a microcosm of the broader maintainer absence problem faced by the massive Linux kernel project.
The Linux kernel contains a large amount of code that was added over its long history but is now rarely used. Hardware drivers are especially prone to this: when devices from the past disappear from the market, their maintainers naturally vanish too. Continuing to keep unused code, like this EFS driver, in the kernel tree incurs non-negligible costs and risks.
On the other hand, from the open-source spirit perspective, the decision to delete code cannot be taken lightly. If even a small number of users need EFS to recover data from old systems, keeping the code holds some value. Linus Torvalds has previously taken the stance that “code should remain as long as it is being used.”
Editorial View
Short-term Impact: This discussion is likely to conclude within the next 3–6 months with the removal of the EFS driver. Even if a new maintainer steps in, maintaining actual code quality without even a test environment is difficult. For the kernel developer community, removing unused code seems a rational step to reduce build times and lower potential security risks.
Long-term Perspective: This issue could spark a rethinking of how the entire Linux kernel codebase is managed. Over a 1–3 year span, we may see a wave of sweeping reviews of old drivers and filesystems in a similar situation to EFS. Distinguishing between code that has a reason to exist (despite low adoption) and code that is merely “negative legacy” will become a community challenge. In particular, from a security standpoint, the risk of leaving unmaintainable code in the kernel is growing year by year.
Editorial Question: Should the kernel’s criteria for retaining code shift from “keep it because it’s being used” to “keep it because someone can responsibly maintain it”? For a huge project like the Linux kernel, it is unrealistic to assign full-time maintainers to every piece of code. However, the time may have come for a minimal mechanism to ensure ongoing code health — for example, an automatic archiving system for code that has seen no maintenance for a certain period. This EFS issue should be seen as a catalyst for that discussion.
References
- Linux EFS File-System May Have New Maintainer - Or It Might Just Get Removed - Phoronix — Published June 8, 2026
Frequently Asked Questions
- Can the EFS filesystem actually be used on current Linux?
- In theory, yes — it is included in the kernel as a read-only driver, so media formatted with EFS can be mounted and read. However, the utility for creating EFS filesystems does not work on modern Linux, and no compatibility verification has been performed.
- Why is there debate about removing old, unused code from the kernel?
- Keeping unmaintained code introduces risks such as build errors from compiler updates and potential security vulnerabilities. Unnecessary code bloat also increases maintenance costs. Especially when no one actually uses the code, removing it is seen as a way to avoid these risks.
- What is the relationship between EFS and XFS, which replaced it?
- XFS is a journaling filesystem developed by SGI as a successor to EFS, and became standard in IRIX 6.0 and later. It was subsequently ported to Linux and is now used as the default or recommended filesystem in many distributions. Although both were developed by SGI, EFS and XFS are based on completely different designs.
Comments