データセットの名前変更後に古いNFSファイルハンドルを解決する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Resolve Stale NFS File Handles After Renaming a Dataset - Zima Store Online

データセットの名前変更後にNFSファイルハンドルが古くなる場合、通常はクライアントが、サーバー上で変更されたオブジェクトまたはエクスポートの識別情報への参照をまだ保持していることを意味します。

最も安全な復旧方法は、古い状態なのが1台のクライアントだけなのか、エクスポートの識別情報自体が変わったのかを確認し、マウントを使用中のアプリケーションを停止して、名前変更後のデータセットが意図したパスからエクスポートされていることを確認したうえで、クライアントを制御された順序で再マウントすることです。古いハンドルがキャッシュされた1台のクライアントのマウントにだけ発生しているのか、名前変更後のエクスポートにアクセスするすべてのクライアントで発生しているのかが分かるまで、すべてのマシンを再起動したり、データセットを再作成したりしないでください。

エラーがデータセットの名前変更時に始まったことを確認する

名前変更前のデータセット名とマウントポイント、名前変更後のデータセット名とマウントポイント、エクスポートされたパス、そして最初にESTALEを返したクライアント操作を記録します。影響を受けたクライアントと、名前変更後に初めて共有をマウントしたクライアントを比較してください。

最近のNFSトラブルシューティング記事では、staleはハンドルが変わったことを意味するのであり、単にネットワークパスが停止していることを示すものではないと説明されています。

新しいクライアントではマウントできるのに、古いクライアントで失敗する場合、名前変更後のエクスポートにはおそらく到達できており、当面の問題は古いクライアントにキャッシュされた状態です。新しいマウントでも失敗する場合は、サーバーのエクスポートとデータセットの識別情報を引き続き調査してください。

エクスポートが現在、意図したデータセットを指していることを確認する

名前変更後に、サーバーで有効なエクスポート一覧とファイルシステムのマウントテーブルを確認します。パスが存在し続けていても、別のデータセット、空のマウントポイント、または誤ったファイルシステム配下のディレクトリを指している可能性があります。

OneUptimeは、オブジェクト、エクスポート、ファイルシステムID、または復元データが既存のクライアント参照の下で変更されると、エクスポートの変更によってハンドルが無効になることがあると説明しています。

クライアントに手を加える前に、エクスポート先を修正してください。誤ったサーバー側パスに対して再マウントすると、ESTALEが解消されたように見えても、アプリケーションが別のディレクトリツリーを参照してしまう可能性があります。

古いマウントを保持しているプロセスを停止する

クライアントのマウントおよびプロセス管理ツールを使用して、古いNFSマウントを開いたままにしているシェル、メディアサーバー、バックアップジョブ、コンテナ、データベースプロセスを特定します。強制アンマウントを行う前に、影響を受けるサービスのうち最小限のものを停止してください。

Linuxの復旧ガイドでは、再マウント前にプロセスを確認することを推奨しています。これにより、復旧操作によってプロセスが中途半端に切り離されたファイルシステムの状態に取り残されるのを防げます。

1つのコンテナだけが古いパスを使用している場合は、まずそのコンテナを停止します。多くのサービスがマウントを共有している場合は、稼働中のアプリケーションスタック全体に対して、すぐに遅延アンマウントを実行するのではなく、短時間のメンテナンス時間を設定してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

サーバー側のパスが安定した後でクライアントを再マウントする

サーバーのエクスポートが正しく、依存するサービスが停止したら、テスト用の1台のクライアントでNFS共有をアンマウントしてから再マウントします。運用環境で使用するサーバーアドレス、エクスポートパス、NFSバージョン、マウントオプションをそのまま使用してください。

NFS移行の事例では、ストレージの移動後はクライアントに新しいマウントが必要になることが示されています。

他のすべてのクライアントを再マウントする前に、ディレクトリ一覧の取得、読み取りを1回、元に戻せる書き込みを1回、そして実際のアプリケーションパスをテストします。同じクライアントですぐに再びstaleになる場合は、再マウントを繰り返すのではなく、サーバーの識別情報に戻って調査してください。

名前変更によってファイルハンドルの識別情報が変わったか確認する

NFSファイルハンドルは通常のパス文字列ではありません。ファイルシステムやinodeに関連する情報を含む、サーバーが定義した識別情報をエンコードしているため、表示上のエクスポートパスが似ていても、基盤となるファイルシステムの置き換え、復元、移動が影響することがあります。

ファイルハンドルの詳細解説では、ファイルハンドルはサーバーの識別情報に対応するのであり、テキストパスへのブックマークのように機能するものではないと説明されています。

その名前変更が実際にはデータセットの削除と再作成、受信、クローン、または復元の一部だった場合は、より大きな識別情報の変更として記録してください。適切な対処は、古いハンドルをいつまでも維持しようとすることではなく、すべてのクライアントを調整して再マウントすることかもしれません。

再起動後もすべてのクライアントが新しいエクスポートを使用することを確認する

最初のクライアントで問題がないことを確認したら、残りのクライアントを1台ずつ再マウントし、依存するサービスを復元します。また、設定済みのマウントユニットやコンテナのバインドパスが意図したエクスポートを参照していることを確認してください。その後、重要度の低いクライアントを1台再起動して、設定が維持されるかテストします。

ストレージのトラブルシューティング記事では、アプリケーションを停止しただけでは古いマウントは残り続けるため、使用中のプロセスとマウント状態を実際に更新する必要があると説明しています。

新しくマウントしたクライアントと再起動後のクライアントのすべてで、ESTALEを発生させずに名前変更後のデータセットをマウントでき、アプリケーションが想定したファイルを読み取れるようになれば、修復は完了です。データセットの名前変更によってローカルのバインドパスやアプリケーションパスも変わった場合は、関連するZimaSpaceガイドの安定したホームサーバーのマウントパスも参照してください。