update: 20141118 今天登录又尼玛满了，上次那样做看来还是没有解决问题。 使用df -i 只能查看整个分区的inode的占用情况 Google之后找到find-where-inodes-are-being-used 用这个脚本
find / -xdev -printf ‘%h\n’ | sort | uniq -c | sort -k 1 -n
#注意-xdev 这个参数，它是将说Don’t descend directories on other filesystems.
最好是>>到一个文本文件. 1051 /usr/src/kernels/2.6.32-431.20.3.el6.x86_64/include/linux 1051 /usr/src/kernels/2.6.32-431.23.3.el6.x86_64/include/linux 1051 /usr/src/kernels/2.6.32-431.29.2.el6.x86_64/include/linux 1063 /root/lnmp1.1-full/php-5.3.28/Zend/tests 1450 /usr/local/mariadb/data/locoyplatform 1450 /usr/local/mariadb/var/locoyplatform 3603 /usr/share/man/man3 3141137 /var/log/mysql 这里很容易就会发现是mysql日志的问题。 这时问题又来了300w+文件的删除，肯定是不能使用rm 会报错 -bash: /bin/rm: Argument list too 只能使用xarg或者rsync 来做删除，前者是统统传递参数，通过把文件名当参数传给xarg来删除。后者则可以通过同步一个空文件夹到目标文件夹来实现删除。
mkdir /tmp/emypy_dir_for_remove_all_files
rsync –delete-before -d -a -H -v –progress –stats /tmp/emypy_dir_for_remove_all_files /var/log/mysql/
这样就删除百万级别的文件了。 删除的过程中可以看到删除了哪些文件，因为使用了-v –progress –stats参数。 其中观察到很多类似的文件例如: deleting mysql.err-20140709-20140716.gz-20140718.gz-20140720.gz-20140722.gz-20140724.gz-20140726.gz 很明显就是logrotate中关于mysql部分的问题了。 vim 之
vim /etc/logrotate.d/mysql
#擦！ 第一行写成了
/var/log/mysql/mysql*
#这样文件不就成指数级增长了… 当时估计是抽风了我.
/var/log/mysql/mysql*.log
#wq退出
logrotate -f /etc/logrotate.d/mysql #测试一下
OK 打完收工 — — — 今天登陆服务器上发现个奇怪的事情，明明用df查看磁盘上还有很多空间，但就是无法pull远程的文件过来一直给我说No space left on device 卡了一会儿经查看原来inode位100%了。 这里非常的奇怪，这台server为backup。所以应该和生产环境中差不多的文件数。看inode居然3.2M了。我勒个大去，哪来的尼玛这么多文件。 master上也就380k.还有2.8M+剩余，太奇怪了。最后在删了backup log之后终于挤出3 inodes.然后yum clean all了一下，哇啦 我擦 瞬间空出来2.8m个inodes. 这里我估计是yum的更新文件出问题了。开来不怎么用的server有时候还是得时不时的看看. EOF.
