☰

I/O 无法挂载 nfs（偶尔）- 服务器超时

tag-icon • tag-icon linux networking network-shares file-transfer nfs
I/O 无法挂载 nfs（偶尔）- 服务器超时

我有一个基于 Linux 的文件服务器（ark），它通过 nfs4 导出 raid 卷。

有时在进行大型复制操作时，它会超时。

[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

系统日志同样没有任何问题。

我收集的一些随机诊断信息：

[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

这不是一个真正的答案，而只是一些故障排除技巧：

  1. 确保问题与 NFS 有关，使用其他协议（例如 SMB）导出同一卷（请参阅这里了解说明）。您是否遇到了同样的错误？或者，尝试使用以下方法复制scp：

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

  2. 这是否仅在复制单个大文件时发生，或者如果您在许多小文件中复制相同数量的数据，是否也会遇到相同的错误？

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

  3. 根据这一页，高 retrans 值表明

    服务器上可用的 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 文件系统上访问的文件的 atime 不会不断更新。

答案2

在我看来，这很像网络问题。有些网卡（尤其是 Realtek 芯片）不太符合标准，尤其是在 1Gbps 速度下，并且中间有一个交换机。因此，您应该尝试：

  • 无需开关即可连接两者
  • 更换以太网电缆
  • 强制将连接速度设置为 1000Mbps 全双工，看看问题是否仍然存在
  • 强制将连接速度设置为 100Mbps 全双工，看看问题是否仍然存在（大多数情况下，不稳定性不会在 100Mbps 时显示，尽管这不是您想要的设置，但它会帮助您缩小不兼容性的范围）
  • 检查ifconfig错误ethtool -S ethX​
  • 检查 MTU 的使用情况ifconfig并将其设置为1500如果更高
  • 用于ping -f检查两者之间是否丢包，尤其是当-s(ping 数据包大小) 值较高时 - 连接不稳定将要当你运行类似程序ping -f -s 10000几秒钟时会出现数据包丢失

答案3

我收到了相同的错误消息（但这不是相同的问题，因为我每次都能重现该错误！）。

更详细地运行 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]

相关内容