Linux VFSが新ファイルシステムに「責任」を突きつける

Linuxカーネルには現在およそ69ものファイルシステムが同居している。そして今、その「増えすぎ」に歯止めをかけるためのドキュメントが用意されつつある。

69個のファイルシステムを抱えるカーネル

Linuxカーネルのソースツリー、fs/ ディレクトリを覗くと、目を疑う光景が広がっている。

開発中のLinux 7.1時点で、カーネルはおよそ69個のファイルシステムを抱えている。EXT4、Btrfs、F2FS、XFSといった現役の主力から、NFSのようなネットワークファイルシステム、procやsysfsのような擬似ファイルシステム、ZoneFSのような特殊用途、そしてBeFSやJFSのような「過去の遺物」に近いものまで、多種多様な実装が同じツリーに収められている。

これだけの数があれば、何かが起きる。新しい機能を仮想ファイルシステム（Virtual File System、以下VFS）層に追加しようとするたびに、その変更を69通りのファイルシステムすべてで動かさなければならない。メンテナーが残っていれば良いが、現実はそうではない。

VFSメンテナーのクリスチャン・ブラウナー（Christian Brauner）たちが直面しているのは、この「放置されたファイルシステム」が引き起こす慢性的な負担だ。

引き金となった2つの新提案

きっかけは、わずか1週間のうちに連続して提案された2つの新ファイルシステムだった。

ひとつはVMUFAT。なんと、セガのドリームキャストに付属していた携帯型メモリーカード「ビジュアルメモリ」（海外名Visual Memory Unit、VMU）のFATベースのファイルシステムをLinuxから読み書きするためのドライバだ。もうひとつはFTRFS（Fault-Tolerant Radiation-Robust Filesystem）。こちらは宇宙空間など放射線が強い環境向けに、CRC32とリード・ソロモン符号によるエラー訂正機能を組み込んだ意欲的な提案である。

性格はまるで違う。一方はレトロゲーム機の懐古的なドライバ、もう一方は宇宙CubeSat向けの先端的な研究実装だ。だが、VFSメンテナーから見れば共通点がひとつある。「マージした後、誰が長期的に面倒を見るのか」が見えにくい、という点だ。

abandoned and untestable filesystems impose on VFS developers, blocking infrastructure changes such as folio conversions and iomap migration. （放棄されてテストもできないファイルシステムがVFS開発者に負担を強いており、folio変換やiomap移行といったインフラ変更をブロックしている）

これは、新しいガイドラインを起こしたパッチのコミットメッセージから引いたものだ。folioへの移行やiomapへの統一といった、近年VFS層が進めている大きな構造改革。それを進めるたびに、誰も触らなくなった古いファイルシステムのコードが「動作確認できない壁」として立ちはだかる。

新しいガイドラインが求めるもの

VFS開発ツリー「vfs-7.2.misc」に投入されたパッチには、Documentation/filesystems/adding-new-filesystems.rst という新しいドキュメントが含まれている。著者はアミール・ゴールドスタイン（Amir Goldstein）、コミッターはクリスチャン・ブラウナー。今夏のLinux 7.2マージウィンドウでの本流入りを目指している。

このドキュメントが投げかける最初の問いは、技術的なものではない。

「そもそも、新しいカーネル内ファイルシステムが必要か？」

ガイドラインは、新規提案者に対してまず代替案を検討するよう促す。

既存のカーネル内ファイルシステムが同じユースケースをカバーしているなら、新規追加よりも改善が望ましい。ニッチな用途であれば、ユーザー空間で動作する FUSE（Filesystem in Userspace）を検討すべきだ。カーネルレベルの性能・信頼性・統合が本当に必要な場合に限り、in-kernel実装の議論に進める。

この姿勢の背後にあるのは、シンプルな計算だ。マージは終点ではなく、出発点である。一度マインラインに入ったコードは、カーネル全体の進化に追随し続ける必要がある。その負担を引き受けられないなら、最初からユーザー空間で動かすほうが、提案者にとっても利用者にとっても幸せだ、という判断である。

技術要件：「新しいAPIで書け」

技術面の要求は容赦ない。

新しいファイルシステムは、Documentation/process/deprecated.rst にリストされた非推奨インターフェースを使ってはならない。ページキャッシュ管理にはfolioを使い、ブロックマッピングとI/Oにはbuffer headsではなくiomapを採用する。ネットワークファイルシステムであればnetfsライブラリの使用を検討する。

加えて、mkfs ツールが必須、fsck ツールも強く推奨。テストにはxfstestsフレームワークを通すことが期待され、ファイルシステム固有のドキュメントも Documentation/filesystems/ に配置しなければならない。

ドキュメントは、古いAPIで書かれたファイルシステムの提出は、レビューで強い反発を招く受け入れがたいメンテナンス負債を生むと明記している。要するに「最初から最新のレールに乗って来てくれ」というVFS側からのメッセージだ。

コミュニティが見ているのは「人」

技術要件以上に重い節がある。「コミュニティとメンテナーシップへの期待」だ。

ファイルシステムをカーネルにマージすることは、長期的なコミットメントだとガイドラインは明言する。具体的には次のような項目が並ぶ。

MAINTAINERSエントリには少なくとも1人のメンテナー、メーリングリスト、gitツリーの記載が必要。メンテナーは2人以上が強く推奨される。理由は明快で、1人のメンテナーが不在になったとき、ファイルシステムが事実上の無人状態に陥るのを防ぐためだ。

過去にカーネルコードのメンテナンス実績があるか、コミュニティ内で既知の信頼を得ているかも考慮される。組織的・企業的なバックアップがあるファイルシステムは、ボランティアの好意だけに依存するファイルシステムよりも長期的な安定性が見込めるとされる。

そしてもうひとつ、興味深い表現がある。

the maintainer is expected to respond to bug reports, address review feedback, and adapt the filesystem to VFS infrastructure changes such as folio conversions, iomap migration, and mount API updates. （メンテナーには、バグ報告への対応、レビューフィードバックへの対処、そしてfolio変換・iomap移行・マウントAPI更新といったVFSインフラ変更への追随が期待される）

つまり、「マージしたら終わり」ではなく、「マージから本番が始まる」 という宣言だ。

「実験的」というラベルと、撤退ライン

ガイドラインの後半には、もうひとつ印象的な節がある。提出プロセスとそれに続く「継続的な義務」についての規定だ。

新しいファイルシステムは、最初の数リリースの間は Kconfig で experimental としてマークするのが適切な場合がある、とされる。コードが安定するまでの期間、利用者に対して「これはまだ実験段階だ」と明示するためだ。

そして、最も重い一文がここにある。

メンテナーが応答しなくなり、インフラ変更に追随できず、テストが不可能になったファイルシステムは、非推奨化と最終的なカーネルからの除去につながりうる

「マージされたら永遠にそこにある」というLinuxファイルシステムの暗黙の了解が、明文化された形で書き換えられようとしている。

なぜ今、ルールを書くのか

ここで一歩引いて考えてみたい。

Linuxカーネルは、リーナス・トーバルズ（Linus Torvalds）が中央集権的に判断していた時代から、無数のサブシステムごとに自治が確立した分散統治モデルへと、長い時間をかけて変化してきた。VFSも例外ではない。クリスチャン・ブラウナーがVFS共同メンテナーに加わり、folioへの移行、iomapの統一、マウントAPIの近代化といった大規模な構造改革が並行して進んでいる。

そうした改革の最中に、互いに無関係な新ファイルシステムが次々と提案されれば、リソース配分の問題は避けられない。ドリームキャストのビジュアルメモリと宇宙線対応ファイルシステムを同列にレビューする時間は、誰も持っていない。

それでも、新しい提案を頭ごなしに拒絶することはLinuxコミュニティの流儀ではない。だからこそ、明文化されたガイドラインが必要になる。「マージするかしないか」を個別の判断にゆだねるのではなく、「最低限これを満たしてから出直してほしい」という共通の物差しを置くことで、議論のコストを下げる。

これは、官僚的なルールづくりというより、疲弊しないための自衛策 に近い。

提案者にとっての意味

ガイドラインの導入は、新ファイルシステムを提案しようとする側にとって何を意味するか。

ハードルは確かに上がる。MAINTAINERSへの2人体制、xfstestsへの対応、folio／iomap前提のコード、mkfs／fsck の整備、そして将来のインフラ変更への追随コミットメント。学習コストも、提出後の継続コストも、これまでより明確に重い。

だが、別の見方もできる。これまで「なんとなく雰囲気で」却下されたり、レビューが進まずに塩漬けになっていた提案にとって、ガイドラインは透明な合格ラインの提示 でもある。要件を満たせば、少なくとも議論のテーブルにつけるという保証が得られる。

VMUFATとFTRFSが今後どう扱われるのかは、まだ見通せない。だが、この2つの提案が引き金となって書かれたドキュメントは、今後何年にもわたってLinuxのファイルシステム提案の「最初の関門」として機能していくことになる。

ファイルシステムの追加は、コードを書いてマージすれば終わる話ではない。10年後、20年後にもそのコードが動き続け、進化し続けるための約束を、誰かが背負わなければならない。Linuxが今やろうとしているのは、その約束の重さを、最初に書面で見せておくことだ。

参照元

• Linux VFS git tree - adding-new-filesystems documentation patch

関連記事

• Btrfsがhuge folios対応、Linux 7.2で投入へ
• Btrfsの書き込み性能、2年越しのバグ修正で最大60%回復
• Linuxに「ドリキャスのメモカ」用ファイルシステムが提案
• Linux 7.0-rc6直前、EXT4に異例の大量バグ修正が投入された
• IntelがUSB4STREAMをLinuxに導入、ケーブル1本でPC間転送
• Linux 7.1で「蘇生」したNTFS、リーナスが刻む皮肉
• Linux 7.1に新NTFSドライバ、NTFS3と併存へ
• トーバルズ、Linux 7.1で2件のプルリクエストを差し戻し
• 宇宙向けFS「FTRFS」10年越しにLinuxへ提案
• Linux 7.0 RC6、異常なパッチ量にトーバルズが「AIツールの影響か」