I / OがNFSのマウントに失敗することがある（時々） - サーバがタイムアウトした

私はnfs4経由でRAIDボリュームをエクスポートするLinuxベースのファイルサーバー（ark）を持っています。

大規模なコピー操作を実行すると、タイムアウトすることがあります。

[nathan@ebisu /mnt/extra/disk] rsync -a --progress . /mnt/raid/backup/backup.extra/disk
sending incremental file list
BSD.0/
BSD.0/BSD.0.vdi
   411336704  12%   48.60MB/s    0:00:56
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write failed on "/mnt/raid/backup/backup.extra/disk/BSD.0/BSD.0.vdi": Input/output error (5)
rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9]
rsync: connection unexpectedly closed (32 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

dmesgが私にそう言うのでこれはタイムアウトであることを私は知っている：

 [nathan@ebisu ~] dmesg | tail
 [52722.138132] nfs: server ark not responding, timed out
 [52722.138137] nfs: server ark not responding, timed out
 [52722.138145] nfs: server ark not responding, timed out
 [52722.138150] nfs: server ark not responding, timed out
 [52722.138154] nfs: server ark not responding, timed out

これがrsyncに関連したバグの可能性があると思う場合は、私も定期的なコピーを試してみました。

[nathan@ebisu /mnt/extra/disk] cp BSD.0/BSD.0.vdi /mnt/raid/backup/backup.extra/disk
cp: error writing ‘/mnt/raid/backup/backup.extra/disk/BSD.0.vdi’: Input/output error
cp: failed to extend ‘/mnt/raid/backup/backup.extra/disk/BSD.0.vdi’: Input/output error

私はこの問題を解決するためにどこを見始めるべきかさえ知りません。どちらもギガビットスイッチを介してギガビットイーサネットで接続されています。私はethtoolを使用して、両方が実際にギガビットの速度で動作していることを検証しました。ホストとサーバー間のほとんどの操作は正常に機能します。それが死ぬのは大きな転送の最中だけです。

ファイルサーバーのdmesgには、厄介なものとして目立つものは何もありません。

[root@ark ~]# dmesg | tail
[    7.088959] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[    7.266363] NFSD: starting 90-second grace period (net ffffffff81880e80)
[ 8492.222871] type=1326 audit(1365926452.334:2): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=336 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fe1be17edc7 code=0x0
[ 8492.314714] type=1326 audit(1365926452.424:3): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=338 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fe30fd9ddc7 code=0x0
[ 8492.405336] type=1326 audit(1365926452.514:4): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=340 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f6bb032ddc7 code=0x0
[ 8492.501048] type=1326 audit(1365926452.611:5): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=342 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f81d7c2fdc7 code=0x0
[ 8492.603056] type=1326 audit(1365926452.714:6): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=344 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f97c8bc9dc7 code=0x0
[ 8492.703732] type=1326 audit(1365926452.814:7): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=346 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f0661b2fdc7 code=0x0
[ 8492.837977] type=1326 audit(1365926452.947:8): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=348 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7fd024f8cdc7 code=0x0
[54125.173195] type=1326 audit(1365972085.286:9): auid=4294967295 uid=99 gid=99 ses=4294967295 pid=353 comm="sshd" sig=31 syscall=48 compat=0 ip=0x7f390a6b9dc7 code=0x0

syslogも同様に問題がありません。

私が集めたいくつかのよりランダムな診断情報：

[root@ebisu etc]# nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
1057273    34163      1050608 

それはたくさんの再送です。

私は自分のnfsdスレッドを飽和させているかどうかを確認しましたが、いいえ、それらはほとんどアイドル状態でした。

楽しみのために、私はディスクエラーやスローを打っていたかどうかを確認するために、完全にローカルで同様の転送を行いました。

[root@ark ~]# rsync --progress test.img /mnt/bigraid/backup/backup.ark/
test.img
  8589934592 100%   48.38MB/s    0:02:49 (xfer#1, to-check=0/1)

sent 8590983238 bytes  received 31 bytes  50386998.65 bytes/sec
total size is 8589934592  speedup is 1.00

50MB / sを少し下回るように見えますが、これは私がリモートrsyncを使っていたときの速度とほぼ同じです。

私はサーバー上でhtopを実行している間に転送を試みました、そして私はしばらくするとnfsdがもっと多くのメモリバッファを要求しているように見えることに気づきました。最近の標準では、サーバーはハイメモリーシステムではないため、メモリーに関連している可能性があります。しかし、これは完全にタイムアウトするのではなく、単に転送が遅くなるようにすべきだと私には思えます。

これは実際には答えではありませんが、いくつかのトラブルシューティングのヒントです。

1. 問題がNFSに接続されていることを確認し、別のプロトコル（SMBなど）を使用して同じボリュームをエクスポートします（を参照）。 ここに 指示については）。同じエラーが発生しますか。または、でコピーしてみてください scp：

   [nathan@ebisu ~] scp root@ark:/mnt/bigraid/backup/backup.ark/test.img .
   

2. これは、1つの大きなファイルをコピーするときにのみ発生しますか。それとも、同じ量のデータを多数の小さなファイルにコピーした場合にも同じエラーが発生しますか。

   split test.img
   rsync -a --progress x* /mnt/raid/backup/backup.extra/disk
   

3. による このページ 高い再送信値は、

   サーバー上の利用可能なNFSカーネルスレッドの数がこのクライアントからの要求を処理するのに不十分であること

   そのため、次のように設定してスレッド数を増やしてみてください。 RPCNFSDCOUNT 変数。あなたのディストリビューションに応じて、これはに設定することができます /etc/sysconfig/nfs またはで /etc/default/nfs-kernel-server （それが私のDebianにあるところです）。のようなものを試してください

   RPCSVCGSSDOPTS=16
   

4. 同じページでは、クライアントでブロックサイズを32に設定することも推奨されています。あなたがあなたから共有をマウントしていると仮定します。 /etc/fstabこれらのオプションを関連する行に追加します。

   rsize=32768,wsize=32768,intr,noatime
   

   読み取り/書き込みブロックサイズを増やすのと同様に、これらのオプションは

   また、ハングアップが発生した場合にNFS操作が中断される可能性があることと、リモートNFSファイルシステム上でアクセスされるファイルの最新の状態が常に更新されないことも保証します。

これは私にとってはネットワークの問題に非常によく似ています。ネットワークカードの中には（特にRealtekチップの場合）、特に1Gbpsで、その間にスイッチが入っているなど、規格にあまり準拠していないものがあります。だから試してみてください：

• スイッチなしで2つを接続する
• イーサネットケーブルの交換
• 接続速度を全二重1000Mbpsに強制し、問題が解決しないかどうかを確認します。
• 接続速度を100Mbps全二重に強制して、問題が解決しないかどうかを確認します（ほとんどの場合、100Mbpsでは不安定さは見られず、これは望みの設定ではありませんが、非互換性を絞り込むのに役立ちます）。
• 確認中 ifconfig そして ethtool -S ethX エラー用
• を使ってMTUをチェックする ifconfig そしてそれをに設定 1500 高ければ
• 使う ping -f 特に高い値で、2つの間でドロップされたパケットをチェックする -s （pingパケットサイズ） - 不安定な接続 意志 次のように実行したときにパケット損失が発生する ping -f -s 10000 数秒間

同じエラーメッセージが表示されました（ただし、毎回エラーが再現される可能性があるため、同じ問題ではありません）。

rsyncをより詳細に実行する （ rsync -vv ）ターゲットファイルシステムがいっぱいであることを明らかにしました。

rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) test/file1 is uptodate test/file2 is uptodate test/file3 is uptodate rsync: recv_generator: mkdir "test/file4" failed: No space left on device (28) * Skipping any contents from this failed directory * rsync: recv_generator: mkdir "test/file5" failed: No space left on device (28) rsync: close failed on "test/file6": Input/output error (5) rsync: connection unexpectedly closed (78708 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]