这个问题通过百度搜索能得出一片的结果，但是其中的结果没有几个是有营养的。
使用google能搜到就比百度有用的多，但是也没有个说是怎么怎么出来的。
因为中工作中遇到了这个问题，也花费了不少的时间去处理 这个问题。希望这篇分析和总结是有用个的。
1.问题描述
这个英文的虽然说的NFS，但是实际上不仅仅NFS系统会遇到这个问题。当然如果你的系统就是NFS的，那么你排查这个问题会简单很多。本文不是针对NFS系统。
Stale NFS file handle具体是什么意思，为还没有看到中文是怎么解释的。英文的意思：文件是变得不可用了。当使用ls， stat，cat等等命令去查看文件的时候会发现无法看到文件的任何信息。
有个问题大家都很熟悉的，就是写程序的时候经常会避免野指针的问题，这个问题与此类似，只是这个野指针是存在于磁盘上的。
2.复现该问题的方法
要重现这个问题不是一般般的简单的，光靠运气会搞死人的。下面给出一种为知道的重现方法：
假设文件系统是/dev/sda2，则可以进行如下操作：
debugfs -w /dev/sda2
这时候会进入到debugfs的命令行中，假设坏掉的文件是/dev/sda2中的file文件，那么使用
stat ./file 命令查看出文件对应的inode，假设是62345
然后使用命令 mi <62345>
修改该文件的Link count数为0
然后quit。
这时候ls去看/dev/sda2的file文件就会出现Stale NFS file handle的报错了（如果不出现，重启系统必定出现）。
3.问题分析
从重现方法就大概知道，是Link count计数不对导致的这个问题。这个报错是系统保持来的。是的没错，就是文件的引用计数出现问题了。一般的，对linux系统来说，文件的引用计数为0表示文件被删除了。这个时候它占用的inode节点要被回收，被它所在目录要去除改文件的目录项。（不清楚文件存储方法的请自行查阅）。
然后，通过debugfs的修改，我们发现，目录还是有这个文件的目录项，但是由于文件的引用计数是0，文件系统认为改文件已经被删除了，那么就意味着根据目录项的该文件的记录是找不到该文件的，即这个目录项是一个野指针。
4.出现的原因
文件系统出问题的原因太复杂了，这里总结两个大家认为不可能但是又十分可能的原因：
系统正在删除文件的时候发生断电，即文件的link count被标记为0，但是对应的目录项还没有来得及删除；
5.解决方法
- 如果文件系统是ext2，那么你会高概率的遇到这个问题，请将系统升级为ext3.（请自行脑补ext2和ext3的对比）
- 使用fsck -y修复文件系统，并且确保系统中启动的过程中会自行修复，这样当系统发生这个问题时可以中启动的时候就自行处理好，而不至于导致系统启动中断掉。
ps
从整个的排查过程来说，个人觉得这个报错信息真的应该改改，有点南辕北辙的意思，如下的链接也在吐槽该问题：
https://bugs.launchpad.net/ubuntu/ source/glibc/ bug/391094
