很早之前就遇到一次这个故障，当时是一台主机故障，这次是上百台主机故障。当时是使用mysqldump向NFS备份时，写数据时大概是NFS出现故障，使得mysqldump进程进入uninterruptible sleep（man ps）状态：
$ps axu|grep mysqldump
mysql 2718 0.0 0.0 51088 672 pts/0 S+ 13:30 0:00 grep mysqldump
mysql 14916 1.4 0.0 0 0 ? D 02:03 10:03 [mysqldump]
进入该状态的进程，会一直等待NFS，不接受任何信号，当然也就无法被杀死（kill/fuser -k）。因为进程一直在运行队列（running queue）中，所以还会导致主机的Load上升（虽然主机并不繁忙）。如果由于这个原因被卡住的进程很多的话，主机的Load可能会看起来非常高。
上次出现这个问题时只有一台主机出了这个症状，当时Google后也注意到很多人有遇到了类似的问题，并且都束手无策(There are some things even root can't do)。Google后，再尝试找了一些Linux原理方面的介绍，依然无解。
解决的终极办法是重启主机（reboot），所以决定等待一段时间（之前遇到过一些僵死进程Z，等待一段时间后也消失了），实在不行就择机重启主机。不过奇怪的是，等了几天过后，这个进程确实消失了（正常结束了？应该是）。
1. Why is Linux so "stupid"?
有人就问，Linux设计是不是有问题，为什么会有一些进程root也无法杀死呢？
jra在How to kill a process in uninterruptible sleep state中给了一个解释：
There's fairly extensive discussion of this in a couple of the kernel
design books, and I think in Nemeth, Snyder and Seebass: the problem stems
from the fact that there are two types of device drivers -- those
for "fast" devices and those for "slow" devices：
Slow-device drivers -- for things like terminals, and such -- are
usually split in two pieces, and can therefore be
interrupted while they're in the middle of something.
Fast-device drivers -- which service things like hard drives and (I
think) ethernet cards -- are designed to expect that
when they call out to hardware, it will respond instantly
(in human terms), and that they won't have to wait
on anything. Such drivers have, as a rule, proven
extremely intolerant of hardware trouble -- if your hard
drive start having to do hardware retries to read a
sector, your system perfromance is going int he toilet,
even if you have more than one drive...大概意思是说，Linux中设备驱动程序可以分为“slow device”和“fast device”两类。磁盘属于“fast device”（如果当作“slow device”处理效率会很低），在这类设备上操作时会以uninterruptible的方式进行。
2. 真的没办法吗?
理论上，除了重启主机，貌似没什么办法了。不过，根据实际经验和运气，也还是有一些办法可以尝试的。
办法1：umount -f
如果是由于NFS故障导致的，可以尝试使用先umount/mount重新挂载NFS。如果NFS无法卸载（如果遇到上述情况，八成是这样），可以尝试使用 -f 参数卸载。最近一次遇到这个故障，有接近上百台主机出现这个故障，就是使用umount -f成功卸载NFS后，相关uninterruptible的进程也都随之正常结束。当时发现，连续重试多次 umount -f 才行：
root>#umount -f /nfsdir
umount2: Device or resource busy
umount: /nfsdir: device is busy
root>#umount -f /nfsdir
umount2: Device or resource busy
umount: /nfsdir: device is busy
办法2：等
最早mysqldump遇到这个问题时，束手无策后，就等了几天，发现进程确实结束了。所以如果情况不是很紧急，“等”也是一个办法。
遇到的僵死进程这个办法也可能有效。
办法3：killall -KILL rpciod
在一篇文章中，还提到，进程处于uninterruptible sleep(即ps的D状态)，进程处于rpc_execute调用状态，而rpc_execute调用是由rpciod提供，所以可以通过杀死rpciod来解决问题。（rpciod被杀死后会自动重启过来）【没有实验过，慎用，希望有经验者分享一下】
办法4：reboot
实在不行，就只能reboot了。这是最不推荐的做法，毕竟每次遇到都reboot，代价还是比较大，特别是当你在追求HA的时候。
3. 能够避免这种情况吗?
在RTFM之后，发现可以通过挂载NFS时指定一些参数，尽可能的避免这个问题：
soft If an NFS file operation has a major timeout then report
an I/O error to the calling program. The default is to
continue retrying NFS file operations indefinitely.
hard If an NFS file operation has a major timeout then report
"server not responding" on the console and continue
retrying indefinitely. This is the default.
intr If an NFS file operation has a major timeout and it is
hard mounted, then allow signals to interupt the file
operation and cause it to return EINTR to the calling
program. The default is to not allow file operations to
be interrupted.上面3个参数，其中hard是默认的。我们通过断开网络模拟NFS故障，测试了 intr 选项，发现能够一定程度上避免上述的情况。在测试 soft 选项时，并没有上面描述的那么好用，在实验中，使用 soft 挂载是现象和 hard 类似（不知道我是不是忽略哪些细节了）。
如果你被这个问题困扰，可以试试使用intr参数挂载NFS：
mount -o intr 172.23.119.25:/nfs /nfsdir