Cisco スイッチおよび LAN のカテゴリ 6 有線ケーブルを使用して RHEL 7.9 を実行します。ある種のネットワーク問題がある場合（時々私が知っている限り、ネットワーク問題ではない場合もあります）、NFSクライアントはNFSのためにLinuxをクラッシュさせます。なぜですか？
例えば
- NFS vers = 4.1はデフォルト設定で、変更
/etc/nfs.confなしで簡単に発生します。/etc/sysconfig/nfs - サーバーAのエクスポート
/data /dataサーバーAからサーバーBをインストールする- 何らかの種類のネットワーク障害が発生した場合は、サーバーAまたはBからCat6ケーブルを抜いて再接続します。ネットワークが再接続され、SSHなどの機能はサーバーAとBの間で正常に機能しますが、NFSクライアントの場合はサーバーBで問題が発生します。この状況では、次の種類の問題を解決する方法がわかりません。
- NFS 古いハンドル
/data - Ctrl-Cが完了するまで、ジョブの実行はターミナル
ls /ウィンドウで中断されます。 - ctrl-cが完了するまで、a実行はターミナル
df -hウィンドウで中断されます。 - 一つだけでも
umount /data中断されます。 - 信頼できる唯一の解決策は、NFSクライアントを再起動するようです。
- NFS 古いハンドル
誰かがこの問題が発生する理由を説明できますか？特にlsand df? NFSの問題を解決する方法についてのガイドラインはありますか？動作が止まったら、まるでブラックボックスを使うような気がし、再起動するだけで解決します。
ベストアンサー1
次回この問題が発生した場合は、/proc/fs/nfsfs/volumesサーバーBを確認してください。マウントされたNFSファイルシステムのリストを見つける必要があります。FSIDそれぞれ。ぶら下がっているインストールのFSIDをメモしてください。その後、クライアントを再起動してNFSボリュームをマウントして、もう一度確認してください。 FSIDは同じままでなければなりません。変更しても同様です。
/dataFSIDが引き続き変更されている場合、エクスポートが実行されるサーバーAからエクスポートされた実際のファイルシステムの種類は何ですか？
ファイルシステムに実際のUUIDがない場合、またはファイルシステムを保持するデバイスのデバイス番号が異なる場合（サーバーAのホットプラグまたは管理操作のため）、何らかの理由でサーバーAに有効な永続FSIDソースがない場合、サーバーAはこれを動的に生成する必要があります。
サーバーBがサーバーAに再接続しようとしたときに別のFSIDを確認する場合は、サーバーBが再接続するNFS共有が以前とまったく同じではなく、サーバーBにキャッシュされたデータがあるとします。古い株式は以下に適用されない場合があります。新しい一つ。
これにより、サーバーBが問題に陥ります。開かれたファイルハンドルとキャッシュされたデータが具体的に参照されます。古い共有はどこにもないようです。ただ盲目的に適用してみてください新しい共有は、データの損失を引き起こすバグかもしれません。そしてカーネルはいいえ明示的な通知なしに意図的にユーザーデータを失います。
カーネルに書き込み待ちのキャッシュされたデータがある場合古いumount /data共有すると、サーバーBの正常な操作は実際に中断されますが、機能umount -l /dataするはずです。残念ながら、この方法を使用すると、よりきれいに終了することができます。umount -lアンマウントされたファイルシステムへの参照を保持しているすべてのプロセスが最初に停止しない限り、アンマウントされた共有を再マウントすることは不可能です。
NFS共有に固定FSIDがない場合は、サーバーAfsid=<number>|root|<uuid>にオプションを追加して/etc/exports固定FSID（有効なUUIDまたは従来の互換性のための単一の小さな整数）を指定する必要があります。
サーバー B がサーバー A の NFS 共有が最初に接続されたときと同じ FSID で再接続されることを発見した場合、自動的に再接続を続行できます。