原文はこちら。
https://blogs.oracle.com/linuxkernel/xfs-whats-new-and-whats-next
昨年、Linux 4.8-4.9で導入され、昨年のこのブログのエントリで取り上げた新しいリバース・マッピングとreflinkの機能を安定させるために大部分の時間を費やしました。
Linux 4.12では、XFSとext4の両方にGETFSMAP ioctlを導入し、ユーザ空間の管理ツールでファイルシステム空間マップ全体を照会できるようにしました。これにより、システム管理者は、メタデータのオーバーヘッドや空き領域の断片化など、ファイルシステム状態のライブ分析を実行できます。XFSでは、新しいxfs_spacemanでこの機能を提供しますが、ext4では、e2fsprogs 1.43.5のe2freefragツールが、マウントされたファイルシステムの検出時にライブクエリを実行するようになっています。 xfsprogsのリリースはカーネルの後になりました。
2017年まで、XFS用のオンラインfsckツールの準備に取り組んできました。既存のXFSコードベースには、メタデータバッファがディスクから読み込まれ、ディスクに書き出される前に、メタデータバッファのスポットチェックを実行する単純なメタデータブロックベリファイア（metadata block verifiers）があります。これらのベリファイアはIOホットパス（IO hot path）に存在するため、スコープが非常に限られています。これらは計算コストの高いチェックは実行できません。具体的には、他のメタデータ構造を相互参照することはできません。書き込みパスのエラーではファイルシステムをシャットダウンします。
こうした課題に対する解決策として、別のオンラインfsckユーティリティがあります。このツールは、ユーザ空間で計算コストの高いチェックをスケジュールし、すべてのチェックで高いコストにならないようにすることで、ベリファイアを拡張します。専用のオンラインfsckツールは、メタデータ値が正確に正しいことを確認することができます。単におおよその範囲内に収まっているかだけをチェックするわけではありません。この最も顕著な例は、逆参照マッピングを使用したブロック参照カウントのチェックです。逆のマッピングツリーを数回歩かなければなりません。他のメタデータと相互参照できる他のすべてもチェックされます。例えば、ファイルデータの範囲が与えられれば、それはinodeではなく、空き領域ではなく、btreeの一部ではなく、拡張属性データとクロスリンクされていないことを保証できます。この種のチェックでは、多くのIOが必要ですが、ユーザー空間ドライバープログラムからIOを管理し、抑制できます。スクラブ作業の一環として、XFSベリファイアを再構成して、破損が見つかった場所をより正確にレポートし、メモリ内バッファの破損を検出するようにします。
オンラインファイルシステム修復は、スクラブ後にしばらくしてから始まりますが、実行可能な修復戦略がメタデータの最初からの再構築しかないため、このタイプの修復は非常に困難です。これを行うには、ファイルシステム全体のすべてのメタデータをロックしてスキャンし、すべての新しいレコードをメモリに作成し、ディスクに書き出す必要があります。続いて、メモリ内の状態すべてを注意深くリセットする必要があります。
Linux 4.15にはスクラブの最初の部分が含まれていましたが、それ以降のリリースでは残りの部分が含まれていました。この機能は一度安定すると、ファイルシステムのダウンタイムをさらに短縮できます。
Allison Hendersonは、XFS親ポインタパッチセットの開発を最近再開しました。XFS親ポインタパッチセットを使うと、拡張属性を設定することで、親ディレクトリのディレクトリエントリへのバックリンクをファイルが記録できます。これにはまず、拡張属性の操作のアトミック性を改良する必要があります。ユーザー空間にフェイルバック可能な通常のファイル属性の操作とは異なり、親ポインタの操作は成功しなければなりません。そうでない場合はファイルシステムが破損しています。親ポインタが配置されたら、オンラインfsckツールを使用してディレクトリツリーの双方向チェックを実行し、ディレクトリを再構築できます。また、書き込みエラーを解決し、影響を受けるファイルパスとオフセットを含むより豊富なログメッセージに記述できるようになります。
将来的には、これらの新しいストレージメディアへの望ましいユーザー空間インターフェイスを詳細に議論できれば、DAXと永続メモリのサポートが改善されるでしょう。この件はメーリングリスト上で多くの議論を呼び起こしましたが、使用モデルやハードウェアは遅れて現れました。mkfsに対して提案された変更があります。これはディストリビューションや管理者が、mke2fsのように、設定ファイルにデフォルトのmkfsオプションを提供できるようにするものです。古いリアルタイムボリュームを再利用して、メタデータと小さなファイルをSSDに保存しながら、SMRドライブにアーカイブデータを記録できるXFSを構築するためのパッチセットも提案されています。
2018年にテクニカルプレビューとして登場予定のすべてのXFSの機能にご期待ください。
https://blogs.oracle.com/linuxkernel/xfs-whats-new-and-whats-next
上流のXFSメンテナンス者であり、Oracle Linuxのカーネル開発者であるDarrick Wongが、XFSに関する1年間の作業の回想を書きました。この中で、最新のLinuxカーネルに登場しているいくつかの素晴らしい機能を暗示しています。（個人的には）オンラインファイルシステムのチェックに期待しています。
昨年、Linux 4.8-4.9で導入され、昨年のこのブログのエントリで取り上げた新しいリバース・マッピングとreflinkの機能を安定させるために大部分の時間を費やしました。
Upcoming XFS Work in Linux v4.8 v4.9 and v4.10+, by Darrick Wong2018年中頃にreflinkからEXPERIMENTALタグを削除する準備をしています。これにより、より良い拡張性を得るために、in-core file extent map cacheを再作成する必要があります。昨年1月にVFSブロックマッピングインターフェイスをiomapに変換しました。3つのIOアクセス方式（バッファ付き、直接、DAX）はすべて、NVMeフラッシュ上でのオーバーヘッドの削減とパフォーマンスの向上のメリットがあります。
https://blogs.oracle.com/linuxkernel/upcoming-xfs-work-in-linux-v48-v49-and-v410%2c-by-darrick-wong
Linux 4.12では、XFSとext4の両方にGETFSMAP ioctlを導入し、ユーザ空間の管理ツールでファイルシステム空間マップ全体を照会できるようにしました。これにより、システム管理者は、メタデータのオーバーヘッドや空き領域の断片化など、ファイルシステム状態のライブ分析を実行できます。XFSでは、新しいxfs_spacemanでこの機能を提供しますが、ext4では、e2fsprogs 1.43.5のe2freefragツールが、マウントされたファイルシステムの検出時にライブクエリを実行するようになっています。 xfsprogsのリリースはカーネルの後になりました。
2017年まで、XFS用のオンラインfsckツールの準備に取り組んできました。既存のXFSコードベースには、メタデータバッファがディスクから読み込まれ、ディスクに書き出される前に、メタデータバッファのスポットチェックを実行する単純なメタデータブロックベリファイア（metadata block verifiers）があります。これらのベリファイアはIOホットパス（IO hot path）に存在するため、スコープが非常に限られています。これらは計算コストの高いチェックは実行できません。具体的には、他のメタデータ構造を相互参照することはできません。書き込みパスのエラーではファイルシステムをシャットダウンします。
こうした課題に対する解決策として、別のオンラインfsckユーティリティがあります。このツールは、ユーザ空間で計算コストの高いチェックをスケジュールし、すべてのチェックで高いコストにならないようにすることで、ベリファイアを拡張します。専用のオンラインfsckツールは、メタデータ値が正確に正しいことを確認することができます。単におおよその範囲内に収まっているかだけをチェックするわけではありません。この最も顕著な例は、逆参照マッピングを使用したブロック参照カウントのチェックです。逆のマッピングツリーを数回歩かなければなりません。他のメタデータと相互参照できる他のすべてもチェックされます。例えば、ファイルデータの範囲が与えられれば、それはinodeではなく、空き領域ではなく、btreeの一部ではなく、拡張属性データとクロスリンクされていないことを保証できます。この種のチェックでは、多くのIOが必要ですが、ユーザー空間ドライバープログラムからIOを管理し、抑制できます。スクラブ作業の一環として、XFSベリファイアを再構成して、破損が見つかった場所をより正確にレポートし、メモリ内バッファの破損を検出するようにします。
オンラインファイルシステム修復は、スクラブ後にしばらくしてから始まりますが、実行可能な修復戦略がメタデータの最初からの再構築しかないため、このタイプの修復は非常に困難です。これを行うには、ファイルシステム全体のすべてのメタデータをロックしてスキャンし、すべての新しいレコードをメモリに作成し、ディスクに書き出す必要があります。続いて、メモリ内の状態すべてを注意深くリセットする必要があります。
Linux 4.15にはスクラブの最初の部分が含まれていましたが、それ以降のリリースでは残りの部分が含まれていました。この機能は一度安定すると、ファイルシステムのダウンタイムをさらに短縮できます。
Allison Hendersonは、XFS親ポインタパッチセットの開発を最近再開しました。XFS親ポインタパッチセットを使うと、拡張属性を設定することで、親ディレクトリのディレクトリエントリへのバックリンクをファイルが記録できます。これにはまず、拡張属性の操作のアトミック性を改良する必要があります。ユーザー空間にフェイルバック可能な通常のファイル属性の操作とは異なり、親ポインタの操作は成功しなければなりません。そうでない場合はファイルシステムが破損しています。親ポインタが配置されたら、オンラインfsckツールを使用してディレクトリツリーの双方向チェックを実行し、ディレクトリを再構築できます。また、書き込みエラーを解決し、影響を受けるファイルパスとオフセットを含むより豊富なログメッセージに記述できるようになります。
将来的には、これらの新しいストレージメディアへの望ましいユーザー空間インターフェイスを詳細に議論できれば、DAXと永続メモリのサポートが改善されるでしょう。この件はメーリングリスト上で多くの議論を呼び起こしましたが、使用モデルやハードウェアは遅れて現れました。mkfsに対して提案された変更があります。これはディストリビューションや管理者が、mke2fsのように、設定ファイルにデフォルトのmkfsオプションを提供できるようにするものです。古いリアルタイムボリュームを再利用して、メタデータと小さなファイルをSSDに保存しながら、SMRドライブにアーカイブデータを記録できるXFSを構築するためのパッチセットも提案されています。
2018年にテクニカルプレビューとして登場予定のすべてのXFSの機能にご期待ください。