春ころから気がついてはいた、FreeBSD バージョン6系で、NFSがささる件。なんと、RC1でも、まだささったので、少しだけ調べてみた。
構成
- Solaris2.6（古いぞ！）がNFSサーバー
- FreeBSDがNFSクライアント。amdでオートマウントしている
- NFSv3、TCPを使ってる（と思う）
症状
- amdなパスをアクセスすると、しばらくの間は使えている。しばらくすると、・・・not respondingとなって、それ以後、NFSが使えなくなってしまう
tcpdump、snoopでパケットをのぞいてみると
- FreeBSD側から、RPC（NFS）のリクエストが再送される。なぜか２つ連続してる
- Solaris側から、１個だけ、TCPのAckが帰ってくる。RPCについて、なんの返事も返さない
- 上記の繰り返し
というわけで、たしかにnot respondingだ。納得。
なんとなく、amdが勝手にunmountしちゃってて、サーバ側ではunmounしたつもりだけど、クライアント側ではmountしたままのつもり？と予想。
amdを使わずにNFSマウントしてみた。
そのまま数時間放置・・・どうも、ささらなくなっているような気がする。
もうちょっと、状況を調べてみてから、なんかの行動を起こしてみようと思う。RELEASEには間に合わないよな。
実は、とある方から、すでに、上記不具合を修正するカーネルパッチをもらっていて、一応、問題は解決していました。動作報告もしたのですが、FreeBSD Currentにcommitされたとか、6-STABLEにマージされたとかいう話は聞いていないので、今どうなってるのかわかりません。
問題の原因は、ブログの「・・・予想」と書いてあるのとは少し違っていて、amdではなくて、カーネル内のNFSクライアントの処理にありました。
SolarisのNFSサーバは、NFSマウント中にアイドル時間がある程度続くと、TCPのコネクションをきってきます。ところが、FreeBSD6のNFSクライアントは、マウント中にコネクションが切られることは「想定外」だった、ということのようです。FreeBSD6なNFSクライアントは、TCPコネクションが切られていることに気が付かず、切れたコネクションに対して、いつまでもNFSのRPCを投げつづけてしまいます。
パッチは、コネクションが生きているかどうかを検出して、切れていたら再接続する、というように変更するものでした（たったの１行パッチでした）。
たぶん一番簡単なワークアラウンドは、amdで、dismount intervalというパラメータを小さい値を指定することです（NFSサーバからコネクションを切られるよりも先にunmountさせてしまう）。あ、amdを使っていない場合には、効果ないですね。
FreeBSD-current ML での議論
http://lists.freebsd.org/pipermail/freebsd-current/2005-November/057815.html
http://lists.freebsd.org/pipermail/freebsd-current/2005-November/057826.html
を見ると、
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/nfsclient/nfs_socket.c
の 1.133, 1.134 での変更がそれでしょうか。1.132 と 1.134 の diff を取ると、確かに 1 行 patch です。
RELENG_6系列では、現在すでに取り込まれていました。