A volunteer has stepped forward to maintain a long-neglected file system driver in the Linux kernel. The catch? They openly admit they have never used it and have no intention of doing so. The confession, reported in a discussion on the Linux kernel mailing list as covered by Phoronix, has reignited a recurring debate in kernel development circles about what responsible stewardship of legacy code actually looks like.
The file system in question is EFS — the Extended File System, one of the earliest file systems written for Linux, predating even ext2. According to Phoronix's report, the EFS driver has sat effectively unmaintained for years. When the question of its future came up on the mailing list, a contributor volunteered to take over maintainership, submitting basic fixes. In a candid exchange, the volunteer acknowledged they don't actually use EFS in any capacity.
That honesty has become the crux of a philosophical tug-of-war. On one side, proponents of keeping the code argue that a willing maintainer — even one without personal experience running the file system — is better than none. EFS may be ancient and rarely deployed, but it still exists in the kernel tree, and someone needs to ensure it doesn't succumb to bitrot (the gradual degradation of unmaintained code). Removing working code, the argument goes, sets a precedent that could shrink the kernel's compatibility footprint over time.
On the other side, sceptics question whether a maintainer who doesn't actively use or test a file system in real-world scenarios can provide meaningful stewardship. Kernel maintenance isn't just about reviewing patches when they arrive; it involves catching regressions, understanding edge cases, and responding to user-reported bugs with context that often only comes from hands-on experience. A volunteer offering basic fixes without operational familiarity may create a false sense of security — the code looks maintained on paper, but the quality of that maintainership could be shallow.
The broader question this raises is one the Linux kernel community grapples with regularly: how much legacy code is too much? The kernel already carries drivers and subsystems for hardware and platforms that few people use, yet their presence supports niche but legitimate use cases. Removing EFS might simplify the codebase, but it could also strand anyone still relying on the file system — whether for archival data, legacy embedded systems, or educational purposes.
The debate also touches on the social dynamics of open-source contribution. The kernel has long operated on a meritocratic model where maintainers earn their roles through demonstrated expertise. Accepting a volunteer whose primary qualification is willingness, rather than deep knowledge of the subsystem, challenges that norm. At the same time, the open-source community has always valued showing up, and turning away a willing contributor carries its own costs.
What makes this case particularly compelling is the volunteer's transparency. Rather than overstating their involvement or expertise, they were straightforward about the limits of their engagement — a quality that, ironically, might make them a better maintainer than someone who overcommits and underdelivers.
The kernel maintainers have yet to reach a final decision on whether EFS gets its new steward or gets dropped from the tree entirely. Whatever they decide could set informal guidelines for how the community handles similar legacy subsystems in the future. For now, the EFS quandary serves as a small but telling case study in the tensions between inclusivity and rigour that define open-source governance — and a reminder that even the oldest corners of the kernel can spark fresh debates about what it means to truly maintain code.
一名自願者挺身而出，願意維護 Linux 核心中一個長期被忽視的檔案系統驅動程式。但問題何在？他們公開承認從未使用過它，而且也無意使用。據 Phoronix 報導，這番坦白出自 Linux 核心郵件列表上的一場討論，重新點燃了核心開發圈內一個反覆出現的辯論：對遺留代碼的負責任管理究竟是何模樣？
所指的檔案系統是 EFS —— 即 Extended File System，它是為 Linux 編寫的最早期檔案系統之一，甚至早於 ext2。根據 Phoronix 的報導，EFS 驅動程式多年來實質上處於無人維護狀態。當郵件列表上提出關於其未來的問題時，一位貢獻者自願接手維護工作，提交了基本修正。在一次坦誠的交流中，該自願者承認他們實際上並未以任何方式使用 EFS。
這種誠實已成為一場哲學拔河戰的關鍵。一方主張保留代碼的人認為，一個願意的維護者——即使沒有親自運行該檔案系統的經驗——總比沒有好。EFS 可能很古老且很少部署，但它仍然存在於核心代碼樹中，需要有人確保它不會 succumb to bitrot（代碼因缺乏維護而逐漸腐壞）。移除可運行的代碼，這種論點認為，會開創一個可能隨時間縮小核心兼容性覆蓋範圍的先例。
另一方，持懷疑態度的人質疑，一個不積極使用或在現實世界場景中測試某檔案系統的維護者，能否提供有意義的管理。核心維護不僅僅是在 patches 到來時進行審查；它涉及捕捉 regressions、理解 edge cases，以及回應用戶報告的錯誤——這通常需要來自實踐經驗的上下文知識。一位提供基本修正但缺乏操作熟悉度的自願者，可能會營造一種虛假的安全感——代碼在紙面上看起來有人維護，但這種維護的質量可能流於表面。
這引發了一個更廣泛的問題，也是 Linux 核心社群經常面對的：多少遺留代碼才算過多？核心已經包含了針對鮮少有人使用的硬件和平台的驅動程式及子系統，但它們的存在支持著小眾但合法的使用場景。移除 EFS 可能會簡化代碼庫，但也可能使任何仍依賴該檔案系統的人陷入困境——無論是為了存檔數據、遺留嵌入式系統還是教育目的。
這場辯論也觸及了開源貢獻的社會動態。核心長期以來遵循精英管理制度，維護者通過展現的專業知識贏得角色。接受一位主要資歷在於意願、而非對子系統有深刻理解的自願者，挑戰了這一規範。與此同時，開源社群一直重視「現身」和付出，拒絕一個願意的貢獻者也有其代價。
使此案例特別引人注目的是該自願者的透明度。他們沒有誇大自己的參與度或專業知識，而是直截了當地說明了他們投入的限度——諷刺的是，這種品質可能使他們成為比承諾過多、交付過少的人更好的維護者。
核心維護者尚未就 EFS 是否獲得其新管理者，或是否從代碼樹中完全移除做出最終決定。無論他們作何決定，都可能為社群未來如何處理類似遺留子系統設定非正式準則。就目前而言，EFS 困境是一個小而具啟發性的案例研究，展現了定義開源治理的包容性與嚴謹性之間的緊張關係——也提醒我們，即使是最古老的核心角落，也能引發關於真正維護代碼意義的新辯論。