Linux EFSファイルシステム削除論争、メンテナー不在とコード保守の限界
LinuxカーネルのEFSファイルシステムドライバをめぐり、新たなメンテナーが現れたものの「自分は使っていない」という奇妙な状況に。コード削除か存続か、コミュニティで議論が進行中。
30年前のSGI IRIX用ファイルシステム、Linuxカーネルから削除の危機
Linuxカーネルのメーリングリストで、古くからメンテナンスされていないコードの取り扱いをめぐり、興味深い議論が起きている。対象となっているのは、EFSファイルシステムドライバだ。ただし、AWSのElastic File System（EFS）と混同してはならない。これはSGI（Silicon Graphics）のIRIXオペレーティングシステムで使われていたExtent File System（EFS）の読み取り専用ドライバであり、非ISO9660のCD-ROMやハードディスクパーティションを扱うためのものだ。
あるオープンソースコントリビューターが、GCCコンパイラの新しいバージョンで未定義変数が発生する問題を修正するパッチを提出したことをきっかけに、このドライバのメンテナー就任を打診した。ところが、その開発者は「自分は実際のEFSファイルシステムを1つも持っていない」と正直に認めている。さらに、EFSファイルシステムを作成するユーティリティが、現代のLinuxシステムでは動作しないことも指摘された。
30年前の遺産、EFSとは何か
EFSは、SGIがIRIX 6.0以前の時代に使用していたブロックデバイス向けファイルシステムだ。1990年代半ばに、より高性能なXFSに置き換えられるまで使われていた。XFSはその後、SGIからLinuxカーネルに移植され、現在でも広く使われているファイルシステムの1つである。
EFSドライバは現在のLinuxカーネルでもソースコードとして残っているが、実際に使用しているユーザーは極めて限られている。IRIXシステム自体がすでに歴史の彼方に消え、EFSでフォーマットされたメディアを読み込む必要があるケースも年々減少している。
こうした状況を踏まえ、Linuxカーネルメーリングリストの議論では、メンテナー不在のコードを削除する方向に関係者の関心が集まっている。実際にEFSを使い続けているユーザーや、古いデータを復旧する必要がある場合は、旧バージョンのLinuxカーネルやLTS（長期サポート）カーネルを使い続ければよいという意見が強い。
メンテナー不在問題が示すLinuxカーネルの構造的課題
この一件は、単なる古いファイルシステムの話にとどまらない。Linuxカーネルという巨大なソフトウェアプロジェクトが抱える、メンテナー不在問題の縮図でもある。
Linuxカーネルには、長い歴史の中で追加されたものの、現在はほとんど使われていないコードが多数存在する。ハードウェアドライバは特にその傾向が強く、過去に製造されたデバイスが市場から消えると、メンテナーも自然にいなくなる。今回のEFSのように、誰も使っていないコードをカーネルツリーに残し続けることのコストとリスクは無視できない。
一方で、オープンソースの精神から言えば、コードを削除する判断も軽々には下せない。仮にごく少数のユーザーが古いシステムのデータ復旧にEFSを必要としているなら、コードを残すことに一定の価値がある。Linus Torvalds氏は過去に「コードは使われている限り残すべき」という立場を示したこともある。
編集部の見解
短期的影響：今回の議論は、今後3〜6ヶ月のうちにEFSドライバの削除という結論に至る可能性が高い。仮に新メンテナーが就任しても、テスト環境すら持たない状態では実質的なコード品質の維持は難しい。カーネル開発者コミュニティとしては、使われていないコードを削除することで、ビルド時間の短縮や潜在的なセキュリティリスクの低減につなげる判断が合理的だと言える。
長期的視点：この問題は、Linuxカーネル全体のコード管理の在り方に一石を投じる可能性がある。1〜3年のスパンで見ると、EFSと同様の状況にある古いドライバやファイルシステムを一斉に精査する動きが出てくるかもしれない。採用率は下がっても、存在理由があるコードと、単なる「負の遺産」として残っているコードをどう区別するか。その基準作りがコミュニティの課題となりそうだ。特にセキュリティの観点から、メンテナンス不能なコードを残すリスクは年々高まっている。
編集部からの問い: カーネルのソースコードを「使われているから残す」のではなく「誰かが責任を持ってメンテナンスできるから残す」という基準に切り替えるべきではないだろうか。Linuxカーネルのように巨大なプロジェクトでは、すべてのコードにフルタイムのメンテナーを割り当てることは現実的ではない。しかし、コードの継続的な健全性を保証する最低限の仕組み——例えば、一定期間メンテナンスが行われなかったコードを自動でアーカイブする仕組み——が必要な時期に来ているのではないか。今回のEFS問題は、その議論のきっかけとして捉えるべきだろう。
参考
よくある質問
- EFSファイルシステムは現在のLinuxで実際に使えるのか
- 読み取り専用ドライバとしてカーネルに含まれているため、理論上はEFSでフォーマットされたメディアをマウントして読むことは可能です。ただし、EFSファイルシステムを作成するユーティリティは現代のLinuxでは動作せず、互換性の検証も行われていません。
- なぜ古くて使われていないコードをカーネルから削除する議論が起きるのか
- メンテナー不在のコードを残し続けると、コンパイラの更新によるビルドエラーや潜在的なセキュリティ脆弱性のリスクが生じます。また、コードベースの肥大化はメンテナンスコストの増加につながります。特に誰も実際に使用していないコードであれば、削除することでこれらのリスクを回避できるという判断があります。
- EFSの代わりに使われているXFSとの関係は
- XFSはSGIがEFSの後継として開発したジャーナリングファイルシステムで、IRIX 6.0以降で標準採用されました。その後Linuxに移植され、現在でも多くのディストリビューションでデフォルトまたは推奨ファイルシステムとして使われています。EFSとXFSは同じSGIが開発したものの、全く異なる設計に基づいています。
コメント