web-dev-qa-db-ja.com

古いNFSファイルハンドルはなぜfsidがそれを解決するのですか？

問題の説明（この問題は解決されていますが、ソリューションが機能する理由についての質問があります）

NFSサーバーはUbuntu 16.04.4 LTSです。クライアントは、Ubuntu 16.04.4 LTSとCentOS 6.10および7の組み合わせです。

NFSサーバーは数か月間正常に動作しており、1つの特定のエクスポートがバックアップのために複数のクライアントにサービスを提供していました。 NFSサーバーディレクトリは次のようになります。

/mnt/backups/client1
/mnt/backups/client2
/mnt/backups/client3
/mnt/backups/client4

/ etc/exportsに含まれるもの：

/mnt/backups 1.2.3.0/24(rw,sync,no_subtree_check)

クライアントはバックアップ中にnfsサーバーのみをマウントし、完了したらバックアップをアンマウントします。

これは正常に機能していましたが、クライアントが/ mnt/backupsディレクトリでお互いを見ることができないようにする必要があると判断されました。各クライアントは同じバックアップuid/gidを使用しています。したがって、/ etc/exportsファイルを使用してディレクトリを分離することが決定されました。

そのために、NFSサーバーが停止され、/ etc/exportsが次の内容を含むように変更されました。

/mnt/backups/client1 1.2.3.21(rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(rw,sync,no_subtree_check)

クライアントがバックアップを実行しているとき（午前4時）にのみNFSサーバーをマウントすることを思い出してください。サーバーでNFSサービスが再起動され、exportfsでエクスポートが確認されましたが、問題ありません。

では、client1をテストします。

mount nfserver:/mnt/backups/client1 /mnt/client1

正常に動作しますが、/ mnt/client1に対するアクションは次のようになります。

cannot open directory /mnt/client1/: Stale file handle

解決するために取られたアクション（これはできませんでした機能します）：サーバーでNFSを再起動しています。クライアントを再起動しています。クライアントとサーバーでlsof | grep/mntを実行して、プログラムがファイルを開いたままにしていないかどうかを確認します。サーバー/クライアントの権限チェック。ここでも、NFS/etc/exportsを古いファイルに切り替え、クライアントからnfsサーバーをマウントすると機能します。 「新しい」方法への切り替えは機能しません。

「restart NFS」のような答えを見つけるためだけに歯、マンページ、STFWを何度も調べた後、私は何年も前にこの問題があったことを思い出しました。マニュアルページを読んだ後、NFSサーバーの/ etc/exportsファイルに以下が追加されました。

/mnt/backups/client1 1.2.3.21(fsid=101,rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(fsid=102,rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(fsid=103,rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(fsid=104,rw,sync,no_subtree_check)

このアクションの後も、実行されたのはサーバー上のexportfs -raだけでした。

これで、すべてのクライアントがNFSサーバーエクスポートをマウントでき、すべて機能します。

なぜそれが解決策なのですか？

ごとにfsidを使用する必要がありますかエクスポート？

this one のようなmanページを読んでも、fsidが解決策である理由を明確に説明していないようです。古いマウントがクライアント側（またはサーバー側）のNFSファイルハンドラーの一種である可能性があるという考えがありましたが、再起動後もその状態が持続するのは奇妙に思えます。

filesystemsmountnfs
6
number9

つまり、fsidは、クライアントとサーバーがマウント後にエクスポートを識別する方法です。

マニュアルページに記載されているように、fsidは、指定されていない場合、基礎となるファイルシステムから派生します。

4つのエクスポートは同じfsidを持っているため、client1がマウントからファイルについて尋ねているときに、サーバーがclient4のエクスポートにアクセスしようとしていると考えている可能性があります（同じfsidの最新のオカレンスのみを保持していると想定しています）。

この仮説を検証する方法はいくつかあると思います。たとえば、4つのクライアントのうち1つ（そして1つだけ）が機能することを確認するなどです。また、client1のエクスポートのみを保持し、他の3はエクスポートせずに、client1が正常に機能することを確認します。

mountpoint -dコマンドを使用してクライアントからfsidをクエリする方法については、 この回答 も参照してください。4つのクライアントから使用して、4つのマウントが同じfsidを持っていることを確認できます。

なぜそれが解決策なのですか？

別個のfsidを使用すると、エクスポートはNFSサーバーに対して別個に見えるため、対応するマウントへのクライアントアクセスに適切に一致します。

すべてのエクスポートでfsidを使用する必要がありますか？

はい、それは良い習慣だと思います。これにより、基盤となるストレージデバイスの制御と変更を維持でき、エクスポートがクライアントに影響を与えることがなくなります。

（私の場合、SANでディスクを使用する一部のNFSサーバーが別の順序でディスクをスキャンすることがあり、再起動後に/ dev/sdhが突然/ dev/sdj。ラベルを使用してマウントすると、正しい場所にマウントされることが保証されますが、fsidが変更され、クライアントが失われます。これは、明らかにサポートされているUUIDが広く普及する前であり、もちろんより優れたソリューションです。これは、ディスクを別の順序でスキャンしても問題はありませんが、fsidを明示的に指定することは悪い考えではなく、完全に制御できます。）

1
filbranden