☰

NFS により、ls や df の実行など、Linux システムがハングします。

tag-icon • tag-icon nfs nfsv4
NFS により、ls や df の実行など、Linux システムがハングします。

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クライアントを再起動するようです。

誰かがこの問題が発生する理由を説明できますか？特に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 で再接続されることを発見した場合、自動的に再接続を続行できます。

答え2

これがNFSの特徴です。 1990年代に私がUNIXを使い始めた時も同じだった。

-o softこのオプションでインストールしてみましたか？役立つことを確認してください。

nfs のマニュアルページは次のとおりです。

       soft / hard    Determines  the  recovery behavior of the NFS client after an NFS request times out.  If neither option
                      is specified (or if the hard option is specified), NFS requests are retried indefinitely.  If the  soft
                      option  is  specified, then the NFS client fails an NFS request after retrans retransmissions have been
                      sent, causing the NFS client to return an error to the calling application.

                      NB: A so-called "soft" timeout can cause silent data corruption in certain cases. As such, use the soft
                      option  only  when  client responsiveness is more important than data integrity.  Using NFS over TCP or
                      increasing the value of the retrans option may mitigate some of the risks of using the soft option.

答え3

場合によっては、以下を使用して復元できます。

 mount -o remount /nfs/mountpoint

失敗した場合は強制的に削除できます。これを行うと破損する危険がありますが、再起動と同じリスクがある可能性があります。

umount -f /nfs/mountpoint

関連情報