Linux 7.2のリリース翌日、Torvalds氏のメインラインにはLinux 7.3向けのVFSプルリクエストが相次いで取り込まれた。ここで消えたのは、SGI IRIXの古いオンディスク形式を読むEFSと、1990年代のUnix互換を担ったFreeVxFSである。同じ日に加わったのが、名前解決を全面的に失敗させ、プロセスを保持済みのファイル記述子へ縛るFailFSである。NILFS2には、O_DIRECT read pathを共通I/O層であるiomapへ寄せる変更も入った。
三つの変更を開発者が一つの方針として宣言したわけではない。ただ、Linux 7.2で整備された新規ファイルシステムの受け入れ文書と並べると、カーネル内に残すコードをどう選ぶかという判断が見える。利用も保守も細りテストが難しくなった互換実装は外す。通常のパス名アクセスでは表せない隔離の意味論には、専用の小さな実装を置く。現役のニッチな実装は、共有されるI/O基盤へ近づける。
3,724行を削り、931行を足す
EFSとFreeVxFSを外すマージは30ファイル、3,724行の削除で、追加はない。EFSはXFS以前のSGI IRIX形式を読むread-onlyドライバで、MAINTAINERSでは孤児（Orphan）扱いだった。FreeVxFSもread-onlyであり、Christian Braunerのプル説明によれば、過去15年間に判明した利用者兼コントリビューターは1人だった。FreeVxFS単体のプルでも19ファイル、2,432行が消えている。
ここで失われるのは、該当するディスク形式をLinuxカーネル内で直接マウントして読む経路である。既存のディスクそのものが壊れるわけではない。EFSについては、カーネル外でデータを取り出すefsextractというユーザー空間ツールもある。古い媒体を今後も扱う組織は、保管物の価値と、カーネルに残す保守負担を切り分ける必要がある。
一方、FailFSのマージは44ファイルで931行を追加し、5行を削除した。セルフテストと文書も含む。行数より、コードが担う役割の差が鮮明である。EFSとFreeVxFSが過去のデータ形式を読む機能だったのに対し、FailFSは、プロセスがファイルシステムをどう参照するかという現在の隔離境界を増やすための機能である。
「空」と「拒否」は違う
FailFSは、ユーザー空間からマウントできないカーネル内部専用の疑似ファイルシステムである。起動時にkern_mount()で1インスタンスだけ作られ、各マウント名前空間とは論理的に別の場所に置かれる。到達したすべてのファイルシステム操作はEOPNOTSUPPで失敗する。これは権限が変われば成功するかもしれないと読めるEACCESやEPERMでも、媒体の異常を思わせるEIOでもない。「この操作を支えない」という失敗を明示する選択だ。
比較対象になるnullfsは、空で不変なディレクトリを提供する。名前を探せばENOENTになるが、rootをopenし、readやstatを行い、その上にmountすることはできる。FailFSはroot inodeをO_PATHでも開けず、statfs()やfstatfs()も失敗する。/proc/filesystems、mountinfo、statmount/listmountにも出ない。空の場所を与えるのではなく、ファイルシステムとしての操作面そのものを閉じる設計である。
この差はサンドボックスにとって重要になる。探索対象がないことと、探索という操作が成立しないことは別だ。前者には後からのマウントや既存rootへの操作が入り込む余地が残る。FailFSは、その可能性を意図的に作らない。
暗黙のroot/cwdを捨て、directory FDを基点にする
FailFSへ入る入口はFD_FAILFS_ROOTというsentinelであり、fchdir(2)と新しいfchroot(2)が解釈する。カレントワーキングディレクトリ（cwd）をFailFSへ移すと、AT_FDCWDを基点にした相対パス検索は失敗し、getcwd()は到達不能を示す。rootをFailFSへ移せば、絶対パス、絶対symlink、動的リンク実行ファイルが参照するPT_INTERPの解決も失敗する。
ただし、既に保持している明示的なディレクトリのファイル記述子（directory FD）を基点にしたopenat()などの探索は続く。プログラムはrootやcwdという暗黙の基点からは歩けず、あらかじめ渡されたFDを能力として使う。FailFSの文書がfilesystem stateに対するRESOLVE_BENEATH相当と説明するのは、このためだ。
無条件に入れる機能でもない。特権付きでfchroot(FD_FAILFS_ROOT, 0)を呼ぶには、呼び出し元ユーザー名前空間のCAP_SYS_CHROOTが要る。非特権で入る場合も、no_new_privsが設定済みであること、すでにchrootされていないこと、fs_structを他プロセスと共有していないことが必要になる。継承FDからsetuid binaryに届く経路、..を使った既存chroot外への脱出、CLONE_FSでroot/cwdを共有する兄弟プロセスとの条件のずれを、それぞれ防ぐためである。
FailFSからの退出は現時点で強く制約できるが、文書は永続的に脱出不能だというABI保証をしていない。FailFSはseccomp、Landlock、mount namespace、通常のchrootを置換する機能でもない。暗黙のファイルシステム状態を捨て、明示的なdirectory FDへアクセスを絞るための追加プリミティブとして読むべきだ。
削除・追加・近代化を分ける基準
Linuxの新規ファイルシステム受け入れ文書は、カーネルに入った実装をVFSメンテナーと広いファイルシステムコミュニティの共同責任と位置付ける。保守されない実装はテストが難しくなり、古いAPIを保存する負担や未修正のバグを積み上げ、基盤の変更を妨げる。新規ファイルシステムには、現行のVFSインターフェースに接続し、必要なユーザー空間ユーティリティを用意することが求められる。意味のあるテストと文書を整え、明確なメンテナーと継続的な保守体制を示す必要もある。追随できなくなった実装は非推奨化と最終的な削除の候補になる。
この基準をそのままFailFSへ当てるのは適切ではない。FailFSはオンディスク形式を実装するファイルシステムではなく、カーネル内部の隔離機構である。それでも、文書と今回の変更を併せて読むと、Linuxが何でもカーネル内へ残すのではなく、共通基盤で表せない意味論と、その保守を支える検証を求めていることは分かる。FailFSは文書とセルフテストを伴っている。
NILFS2の扱いは第三の道を示す。Linux 7.3向けの更新では、O_DIRECT read pathがiomapへ移された。iomapはブロックマッピングとI/Oを共通化する層であり、新規ファイルシステム文書もブロック型ファイルシステムにはbuffer headsではなくiomapを使うよう求める。NILFS2を削除するのではなく、共通基盤に寄せて維持する方向である。
Linux 7.3で確認すべき点
これらの変更は8月17日にmainlineへ統合された段階で、Linux 7.3の正式リリースはまだ先にある。リリース候補（RC）期間で確認すべきなのは、削除が既存のビルドや古い媒体の運用にどこまで影響するか、そしてFailFSの新しい経路が各アーキテクチャやセルフテストでどう振る舞うかだ。
ユーザー空間側も重要になる。fchroot()のlibcラッパーやman-pagesへの収録、コンテナランタイムやサンドボックスがこのプリミティブを採用するかは、現時点で決まった話ではない。FailFSの価値は、カーネルに入ったことだけでは測れない。FDを中心に設計された実行環境が、暗黙のroot/cwdを断つこの境界をどこで使うかによって、実務上の輪郭が決まる。
