MeshXFS、AIが書いたXFSベースのクラスタファイルシステム

MeshXFSは、複数のLinuxサーバーが1台のディスクを同時に共有できる、新しいオープンソースのファイルシステムです。Phoronixが2026年10月17日に報じたところによると、AIコーディングエージェントを使ってXFSを改変することで作られました。プロジェクトのリポジトリによると、クラスタリングのコードは、人間が書いたものではなく、人間が手で編集したことも、1行ずつレビューしたこともありません。そのため、バグがデータを破壊しかねない領域でAIが書いたコードを試す、これまでで最も分かりやすい事例の1つになっています。

XFSは、Linuxカーネルに含まれている成熟したファイルシステムです。通常のXFSボリュームは、一度に1台のマシンからしかマウントできません。クラスタファイルシステムを使うと、複数のマシンが同じ共有ディスクをマウントし、一緒に書き込むことができます。これは仮想化クラスタでよく使われる構成です。

コードはどのように書かれたか

プロジェクトのGitHubページによると、AnthropicのClaude Codeで自律型コーディングエージェントとして動くClaude Opusが、コードの「かなりの部分を書いた」とのことです。最も難しい問題については、Claude Fable、GPT、Gemini、Astraにも意見を求めました。リポジトリはStephen P. Shoecraft氏が管理しています。リポジトリでは、人間の役割を、作業の指揮、要件の設定、テストと説明しています。

リポジトリには「クラスタリングのコードは、人間が書いたものでも、手で編集したものでも、1行ずつレビューしたものでもない」と書かれています。Phoronixによると、テストを書いて実行したのもAIエージェントでした。

変更の規模は大きなものです。Phoronixとリポジトリの両方によると、プロジェクトのxfs/ツリーは約22万6,000行から約31万4,000行に増えました。MeshXFSは、Linux 6.19開発ツリーにあるXFSのコードのフォークです。ライセンスは、GNU General Public Licenseのバージョン2です。

Phoronixは、プロジェクトの目標として「データの整合性を最優先し、ホストを決してクラッシュさせず、同じストレージ上でネイティブのXFSにかかる時間の2倍以内に収める」という言葉を引用しています。

MeshXFSがクラスタを構成する仕組み

複数のマシンが1台のディスクに書き込むには、互いのデータを上書きしないためのルールが必要です。Phoronixとリポジトリによると、MeshXFSはそのためにいくつかの標準的な仕組みを使っています。

• ロックマネージャー。 1つは、ノード間のネットワーク越しに動作します。もう1つは、SCSI COMPARE AND WRITEというストレージコマンドを使い、共有ディスク自体にロックの状態を保持します。
• フェンシング。 あるノードが応答しなくなると、ほかのノードがそのノードをディスクから切り離し、データを壊せないようにします。MeshXFSは、これをSCSI persistent reservationsで行います。
• リカバリー。 各ノードは、保留中の変更を記録するログであるジャーナルのうち、自分専用の部分を持っています。生き残ったノードは、停止したノードをフェンシングし、そのジャーナルを再生して処理を続けます。

リポジトリによると、ほかのノードには、ノードの停止を判定するまでに120秒、そのノードのフェンシングを完了するまでに180秒が与えられています。

リリース済みのものと未リリースのもの

最新バージョンは0.90.130で、「Stronger Recovery, Broader Platform Support」（リカバリーの強化と対応プラットフォームの拡大）と題されています。リポジトリは、その限界を具体的に示しています。

項目	リポジトリ上の状況
クラスタの規模	2、4、8、16ノードでリリース済み。32ノードは実装済みだが未リリース
ストレージの接続	iSCSIは検証済み。Fibre ChannelとSASは未検証
NVMeとNVMe-oF	非対応。フェンシングとロックがSCSIコマンドに依存しているため
ストレージアレイ	「ストレージアレイ上で検証されたリリースはない」
未解決の不具合	123件の記録。うち69件はリリース済みの構成に及ぶ
パッケージ	Proxmox VE 9、RHEL 9、Ubuntu 24.04と26.04、Debian 12と13向けのDKMSモジュール

Phoronixによると、各リリースでは、実際のマルチノードクラスタ上で、構成ごとに約30行のテストスイートを実行しています。リポジトリには、目立つ警告も2つ掲載されています。「MeshXFSのツールを使い、標準のXFSツールは決して使わないこと」と、「0.90.37以前を使っていますか？アップグレードしてください」です。

このプロジェクトが登場したのは、Linuxカーネルの開発者たちが、コミットからAIのAssisted-byタグを廃止する方向に動いた翌日のことです。MeshXFSは、カーネルの外にある別のプロジェクトです。それでも、AIが書いたコードにどれだけのレビューが必要かという、同じ問いを投げかけています。

開発者にとっての意味

• まだ本番のデータを置かないこと。 プロジェクトは、リリース済みの構成に及ぶ未解決の不具合を69件挙げており、ストレージアレイ上で検証されたリリースはないとしています。検証用のプロジェクトとして扱ってください。
• 共有ストレージのクラスタを運用しているなら試すこと。 iSCSIストレージ上でProxmoxなどの仮想化スタックを使っている場合、検証環境で試せば、フェイルオーバーの様子が分かります。ノードの電源を抜き、フェンシングにかかる時間を計って、公表されている180秒と比べてください。
• まずストレージのプロトコルを確認すること。 NVMeとNVMe-oFには、まったく対応していません。Fibre ChannelとSASは未検証です。
• 標準のXFS修復ツールを決して実行しないこと。 プロジェクトは、標準のXFSツールがMeshXFSのディスク上で誤った場所を読み取ると警告しています。プロジェクト独自のツールを使ってください。
• 不具合リストを手本として読むこと。 未解決の不具合を深刻度と構成ごとに公開するのは、AIが書いたかどうかにかかわらず、どのプロジェクトにとっても役立つ習慣です。何が主張されているのかを、ユーザーに正確に伝えられます。