我们有一个内部“计算场”，其中有大约 100 台 CentOS（RHEL 的免费重新分发）5.7 和 6.5 x86_64 服务器。（我们正在将所有 5.7 机器升级到 6.5。）所有这些机器都对两台 CentOS 6.5 服务器执行两次 NFSv4 挂载（sec=krb5p）。一台 NFS 服务器用于用户主目录，另一台服务器包含用户进程的各种数据。
随机地，其中一台客户端计算机会进入不良状态，导致对 NFSv4 安装的任何访问都会挂起（例如“ls”）。这意味着没有人（root 除外）可以登录，并且所有需要访问共享的用户进程都会卡住。换句话说，到目前为止，这是不确定的，无法复制。
我在客户端和服务器上都启用了非常详细的 NFS 日志记录，但从未收到任何错误。但是，当触发此状态时，我确实在客户端计算机上收到以下内核跟踪错误：
Mar 25 00:49:48 servername kernel: INFO: task ProcessName:8230 blocked for more than 120 seconds.
Mar 25 00:49:48 servername kernel: Not tainted 2.6.32-431.el6.x86_64 #1
Mar 25 00:49:48 servername kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 25 00:49:48 servername kernel: ProcessName D 0000000000000000 0 8230 8229 0x00000000
Mar 25 00:49:48 servername kernel: ffff8804792cdb68 0000000000000046 ffff8804792cdae8 ffffffffa0251940
Mar 25 00:49:48 servername kernel: ffff88010cdc8080 ffff8804792cdb18 ffff88010cdc8130 ffff88010ea5c208
Mar 25 00:49:48 servername kernel: ffff88047b011058 ffff8804792cdfd8 000000000000fbc8 ffff88047b011058
Mar 25 00:49:48 servername kernel: Call Trace:
Mar 25 00:49:48 servername kernel: [<ffffffffa0251940>] ? rpc_execute+0x50/0xa0 [sunrpc]
Mar 25 00:49:48 servername kernel: [<ffffffff810a70a1>] ? ktime_get_ts+0xb1/0xf0
Mar 25 00:49:48 servername kernel: [<ffffffff8111f930>] ? sync_page+0x0/0x50
Mar 25 00:49:48 servername kernel: [<ffffffff815280a3>] io_schedule+0x73/0xc0
Mar 25 00:49:48 servername kernel: [<ffffffff8111f96d>] sync_page+0x3d/0x50
Mar 25 00:49:48 servername kernel: [<ffffffff81528b6f>] __wait_on_bit+0x5f/0x90
Mar 25 00:49:48 servername kernel: [<ffffffff8111fba3>] wait_on_page_bit+0x73/0x80
Mar 25 00:49:48 servername kernel: [<ffffffff8109b320>] ? wake_bit_function+0x0/0x50
Mar 25 00:49:48 servername kernel: [<ffffffff81135bf5>] ? pagevec_lookup_tag+0x25/0x40
Mar 25 00:49:48 servername kernel: [<ffffffff8111ffcb>] wait_on_page_writeback_range+0xfb/0x190
Mar 25 00:49:48 servername kernel: [<ffffffff81120198>] filemap_write_and_wait_range+0x78/0x90
Mar 25 00:49:48 servername kernel: [<ffffffff811baa3e>] vfs_fsync_range+0x7e/0x100
Mar 25 00:49:48 servername kernel: [<ffffffff811bab2d>] vfs_fsync+0x1d/0x20
Mar 25 00:49:48 servername kernel: [<ffffffffa02cf8b0>] nfs_file_flush+0x70/0xa0 [nfs]
Mar 25 00:49:48 servername kernel: [<ffffffff81185b6c>] filp_close+0x3c/0x90
Mar 25 00:49:48 servername kernel: [<ffffffff81074e0f>] put_files_struct+0x7f/0xf0
Mar 25 00:49:48 servername kernel: [<ffffffff81074ed3>] exit_files+0x53/0x70
Mar 25 00:49:48 servername kernel: [<ffffffff81076f4d>] do_exit+0x18d/0x870
Mar 25 00:49:48 servername kernel: [<ffffffff81077688>] do_group_exit+0x58/0xd0
Mar 25 00:49:48 servername kernel: [<ffffffff81077717>] sys_exit_group+0x17/0x20
Mar 25 00:49:48 servername kernel: [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
此时，使机器再次可用的唯一可靠方法是重新启动它。（即使这样也需要硬电源循环，因为当软件尝试卸载 NFS 文件系统时，软件重启会挂起。）
它似乎此类问题与发生故障并开始疯狂写入数据的进程相关。例如，生成巨大核心文件的段错误，或紧密打印循环的错误。
但是，我尝试在实验室环境中复制此问题，使用多个“dd”进程对 NFS 服务器进行猛烈攻击，但所有机器都运行正常。
答案1
CentOS 6.5 中的内核 2.6.32-431.el6 存在问题。提出问题时，这是一个相当老的内核。我们查看了 RHEL/CentOS 内核的更新日志，发现有很多与 NFS 相关的活动。因此，我们升级到了最新的 CentOS 6.6 内核，2.6.32-504.12.2.el6，从此以后就没再遇到过这个问题。