EXT3_DX_ADD_ENTRY: DIRECTORY INDEX FULL!
EXT3_DX_ADD_ENTRY: DIRECTORY INDEX FULL!
inode问题故障1例
故障关键字：ext3_dx_add_entry: Directory index full!
线上业务的一台服务器无缘无故突然挂了
让机房帮忙连接显示器后发现报错
http://image.kbnix.com/Blog/monitor_error.jpg
遂让机房重启了
重启后能正常进入系统，查看/var/log/message后，依然发现有这个报错，而且是持续了很久了，看来是没关注好这类型错误
先是马上查看了硬盘的inode数
df -i看，没有异常，inode use采用了14%
再Google一下，说是ext3文件系统单个目录下不能超过32000个节点
然后就查一下到底是哪个目录占用inode过多了
for i in /*; do echo $i; find $i |wc -l; done
这时候在/var目录下卡住了半天不出结果
接着进入/var里面查看一下
先是看了/var下的xdebug目录跟tmp目录，都是空的，没有异常
随手进入了spool目录
ll一看，惊呆了，其他目录都是4096大小的，里面的一个目录clientmqueue是一个天文数字
ll -h一看，1017M的目录。。。我去，这里面隐藏了多少inode
马上Google之，说是计划任务cron由于没有把输出重定向掉，而导致的，cron会把执行的计划任务的输出以mail的形式发给指定的管理员账户，默认是发给root的，然后由于没有安装或者开启sendmail服务，就会把邮件积压在这个目录里面
马上检查crontab，/etc/crontab，/etc/cron.d/*，/var/spool/cron/root，都看了，所有计划任务都是加了重定向>/dev/null 2>&1的
那就奇怪了，怎么没效果呢
马上把目录移除掉rm -rf，rsync –delete，ls | xargs rm -f都好像卡死了一样没效果
果断把它先mv掉，然后重建一个给它，发现cron继续往里面写文件了，看一下内容，都是cron的输出，重启一下crond看看，还是老样子，没效果，继续写
暂时解决办法：
把clientmqueue目录mv掉，不建立目录了，让cron无处可写，然后现在挂在screen里用rsync –delete的方法来删掉mv过的clientmqueue目录，挂了一晚，一直还卡在那，想看看有没在删
ps aux | grep rsync获取pid，然后strace -p pid，看到进程一直在unlink了，这下才放心，确定它是一直在删除的了
df -i再看看，inode use降到了8%了，目前还在删
—
后续
删了1天半，终于删完了
后面把sendmail服务删掉就没有再往clientmqueue写文件了
yum remove sendmail