老话重提:i节点导致系统无法写入

简介:

1、在服务器上编写一个脚本,然后提示“设备上没有空间”

wKiom1mvsxLCNBppAAA6pWUFqfE875.png

2、查看i节点的使用情况,发现空间还真被占满了

wKiom1mvs7nz7VWDAAAlozP3yW4241.png

可以通过以下命令快速查找文件目录下的文件个数:

for i in /*; do echo $i; find $i | wc -l; done  

3、衍生出的问题

后来发现,一个同事在写测试脚本的时候,生成了大量的小文件在根目录的/test,使用rm -rf /test目录时,报错,可能是文件数太多:

解决方法:

1
2
mkdir  -p  /blanktest
rsync  -a --delete  /blanktest/  /test

文件很快被删除了

小结:把文件系统的目录与书籍的目录做类比,rm删除内容时,将目录的每一个条目逐个删除(unlink),需要循环重复操作很多次;rsync删除内容时,建立好新的空目录,替换掉老目录,基本没开销。

4、监控注意事项

我们在做监控的时候,除了传统的资源利用率外,最好也能将一些比较重要的分区的i节点进行监控,做好监控,可以及时的发现并解决问题。










本文转自 冰冻vs西瓜 51CTO博客,原文链接:http://blog.51cto.com/molewan/1964513,如需转载请自行联系原作者
相关文章
彻底解决K8S节点本地存储被撑爆的问题3
彻底解决K8S节点本地存储被撑爆的问题3
349 0
彻底解决K8S节点本地存储被撑爆的问题2
彻底解决K8S节点本地存储被撑爆的问题2
174 0
彻底解决K8S节点本地存储被撑爆的问题4
彻底解决K8S节点本地存储被撑爆的问题4
294 0
间歇性宏图大志,持续性混吃等死...
间歇性宏图大志,持续性混吃等死...
89 0
临近年关,发生两起磁盘占满引发的服务下线故障
一口气说两个因为磁盘空间不足引发的应用故障。
临近年关,发生两起磁盘占满引发的服务下线故障
黑科技揭秘:阿里云如何做到从业务宕机到恢复业务运行只用一分半钟时间
企业关键业务宕机会带来非常大的损失,而传统的自建容灾方案成本高昂运维复杂,因此高性能的云容灾服务正在成为企业业务持续性保障的优先选择。混合云容灾服务(HDR)-关键业务型的演示完整呈现了将本地服务器上运行的报账系统实时容灾复制到阿里云,并在出现宕机后在云上快速拉起恢复业务的全过程。
3417 0
可用性监控-先于用户知道应用挂了
背景:任何服务都避免不了出现以下问题,你的用户访问不了你的服务或者站点,用户偶尔碰到5xx,服务响应延迟比较慢,某台应用进程挂掉,导致访问时好时坏。问题在于,_你是否要等你的用户来告诉你,你的程序是问题了_。
1909 0