我们拥有一个拥有约100 CentOS（免费重新分配RHEL）5.7和6.5 x86_64服务器的内部“计算场”。 （我们正在将所有的5.7盒升级到6.5）。所有这些机器对两台CentOS 6.5服务器执行两次NFSv4挂载（sec = krb5p）。 一个NFS服务器用于用户主目录，另一个包含用于用户进程的各种数据。
随机地，其中一台客户端机器将进入一个坏的状态，因此任何对NFSv4挂载的访问都会挂起（例如“ls”）。 这意味着没有人（root除外）可以login，并且所有需要访问共享的用户进程都卡住了。 换句话说，到目前为止，这是非确定性的，不能被复制。
我在客户端和服务器上都启用了非常详细的NFS日志logging，但是从来没有得到任何错误。 但是，当这个状态被触发时，我确实在客户端机器上遇到这些内核跟踪错误：
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服务器上重复这个问题，但是所有的机器都很高兴。
内核2.6.32-431.el6与CentOS 6.5存在问题。 在提出这个问题的时候，这是一个相当古老的内核。 我们查看了RHEL / CentOS内核的更新日志，并看到了很多与NFS相关的活动。 于是我们升级到了最新的CentOS 6.6内核2.6.32-504.12.2.el6 ，并且没有遇到过这个问题。