我们发现的问题是，我们的一些 NFS 挂载目录正在消失。真的消失了。它们在服务器端仍然存在。
在客户端（CentOS 7.4，使用el-repo 的 kernel-ml在版本 4.16.6，nfs-utils-1:1.3.0-0.48.el7) 结束时驱动器无响应。调用ls /mountpoint只是挂起。操作系统仍然认为驱动器已安装 - 重新启动服务器需要硬重置，因为关机过程会在卸载驱动器时挂起。
在日志中我们看到的信息非常少 — 在服务器端我们什么也看不到。有时（但不是每次）我们会在客户端的 /var/log/messages 中看到类似这样的信息：
May 29 16:55:22 papr-res-compute06 kernel: INFO: task STAR:1370 blocked for more than 120 seconds. May 29 16:55:22 papr-res-compute06 kernel: Not tainted 4.16.6-1.el7.elrepo.x86_64 #1 May 29 16:55:22 papr-res-compute06 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 29 16:55:22 papr-res-compute06 kernel: STAR D 0 1370 1351 0x00000080 May 29 16:55:22 papr-res-compute06 kernel: Call Trace: May 29 16:55:22 papr-res-compute06 kernel: __schedule+0x290/0x890 May 29 16:55:22 papr-res-compute06 kernel: ? out_of_line_wait_on_atomic_t+0x110/0x110 May 29 16:55:22 papr-res-compute06 kernel: schedule+0x36/0x80 May 29 16:55:22 papr-res-compute06 kernel: io_schedule+0x16/0x40 May 29 16:55:22 papr-res-compute06 kernel: bit_wait_io+0x11/0x50 May 29 16:55:22 papr-res-compute06 kernel: __wait_on_bit+0x66/0x90 May 29 16:55:22 papr-res-compute06 kernel: out_of_line_wait_on_bit+0x91/0xb0 May 29 16:55:22 papr-res-compute06 kernel: ? bit_waitqueue+0x40/0x40 May 29 16:55:22 papr-res-compute06 kernel: nfs_wait_on_request+0x4b/0x60 [nfs] May 29 16:55:22 papr-res-compute06 kernel: nfs_lock_and_join_requests+0x12a/0x540 [nfs] May 29 16:55:22 papr-res-compute06 kernel: ? radix_tree_lookup_slot+0x22/0x50 May 29 16:55:22 papr-res-compute06 kernel: nfs_updatepage+0x120/0x9f0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: ? nfs_flush_incompatible+0xc5/0x1c0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: nfs_write_end+0xe2/0x3c0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: generic_perform_write+0x10b/0x1c0 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: nfs_file_write+0xd4/0x250 [nfs] May 29 16:55:22 papr-res-compute06 kernel: do_iter_readv_writev+0x109/0x170 May 29 16:55:22 papr-res-compute06 kernel: do_iter_write+0x7f/0x190 May 29 16:55:22 papr-res-compute06 kernel: vfs_writev+0x84/0xf0 May 29 16:55:22 papr-res-compute06 kernel: ? handle_mm_fault+0x102/0x220 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: do_writev+0x61/0xf0 May 29 16:55:22 papr-res-compute06 kernel: SyS_writev+0x10/0x20 May 29 16:55:22 papr-res-compute06 kernel: do_syscall_64+0x79/0x1b0 May 29 16:55:22 papr-res-compute06 kernel: entry_SYSCALL_64_after_hwframe+0x3d/0xa2 May 29 16:55:22 papr-res-compute06 kernel: RIP: 0033:0x7f0cc1563230 May 29 16:55:22 papr-res-compute06 kernel: RSP: 002b:00007fff6f75f2c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000014 May 29 16:55:22 papr-res-compute06 kernel: RAX: ffffffffffffffda RBX: 0000000000002025 RCX: 00007f0cc1563230 May 29 16:55:22 papr-res-compute06 kernel: RDX: 0000000000000002 RSI: 00007fff6f75f300 RDI: 000000000000000a May 29 16:55:22 papr-res-compute06 kernel: RBP: 000000001a7b0860 R08: 0000000000000000 R09: 00007f0cc15b8a00 May 29 16:55:22 papr-res-compute06 kernel: R10: cccccccccccccccd R11: 0000000000000293 R12: 000000000000000a May 29 16:55:22 papr-res-compute06 kernel: R13: 00007fff6f75f300 R14: 0000000000000028 R15: 0000000000001ffd
我们无法可靠地重现此错误。驱动器丢失的情况之间几乎没有共同点 - 这是在拥有大约 40 台服务器和 100 个用户的 HPC 上发生的。通常只影响一台服务器，但会发生在硬件上（Cisco UCSB-B200-M4 w 368GB 和 UCSME-142-M4 w 32GB）。唯一常见的是，有问题的驱动器保存着生物数据，这些数据可能非常大（有时超过半 TB）。
因此，我们希望监控 NFS 驱动器是否启动，因为 SLURM 不断将作业分配给存在此问题的服务器，而这些作业永远不会完成。
我的同事编写了几个 shell 脚本，用于执行ping各种ls操作，并在必要时写入文件和电子邮件。这很聪明，编写起来很有趣（awk！，cut！），但在我看来，这绝对是错误的做法。
快速谷歌搜索显示这nfsiostat可能很有用，但是几乎没有好的说明，现有的内容似乎没有映射到我们的操作系统（特别是“count”是必要的，尽管手册页是这么说的）和最重要的是，我们不需要使用情况统计信息。我们需要存在信息。字面意思是“你在 nfsdrive 那里吗，是我 root？”我承认我需要阅读更多有关 nfsiostat 的内容。
我见过的另一种解决方案是从 fstab 中列出的 nfs 挂载转移到使用 autofs。CentOS 文档在两个版本前完成但请声明：
对于一两个挂载来说这不是问题，但是当系统同时维护对许多系统的挂载时，整个系统的性能就会受到影响。
考虑到我们有大约 10-12 个挂载点 - 这算多吗？我的同事建议“很多”应该在 100 个左右。无论如何，这些信息现在已经过时了。查看Redhat 文档，我们看到这是一个复制/粘贴。
我见过这两个勘误表/错误
- https://access.redhat.com/errata/RHBA-2018:0981
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/bug_fixes_file_systems
但我们无法立即升级，因为服务器是生产服务器，并且处于临床环境中。此外，没有迹象表明这显然是我们的问题，而且鉴于我们无法随意重现问题，我们无法在我们的开发机器上进行测试 - 尽管我一直在尝试在我们的开发机器上重现。还有更新的 El Repo kernel-ml 版本，但存在同样的问题 - 无法在一夜之间更新 - 这些服务器通常 24/7 处于 100% 的状态。
所以，我想我有两个问题：
- 人们所知道的监控驱动器存在的最佳方法是什么（即 - grepping mount 是一个不可接受的答案）
- 我们是否应该从 /etc/fstab 迁移到 autofs （如果我们这样做，可能还会包括内核和操作系统更新）