一、问题背景
一台数据库服务器,突然监控告警,报根目录空间不足(no space left on device),登录机器初步查看,发现根目录确实满了。
# df -hT
二、问题排查
根目录下包括所有的目录,而有些目录是挂了盘的,这些目录不会占用根目录下的系统磁盘空间。
出现根目录空间不足的情况只要关注那些未挂盘的文件大小,使用du命令查看各个目录的大小(只显示一层目录)
# du -h --max-depth=1 /
但是却并没有发现某个目录下有特大的文件存在。
灵机一动,是否有文件已被删除,但是引用该文件的进程仍然活动,导致文件所占磁盘没有被释放。
# lsof | grep deleted
根目录磁盘空间已满,根目录没有大文件,文件如果正在使用的时候被删除,进程可以继续读取文件,文件仍然占用空间,导致文件被删除但是空间未释放。
解决方法是删掉占用文件的进程,但结果中仍然没有发现有大文件。
有没有可能是这台服务器的block虽然还有剩余,但inode已经用满,因此在创建新目录或文件时,系统提示磁盘空间不足?
inode译成中文就是索引节点,每个存储设备(例如硬盘)或存储设备的分区被格式化为文件系统后,应该有两部份,一部份是inode,另一部份是 block,block是用来存储数据用的,而inode就是用来存储这些数据的信息,这些信息包括文件大小、属主、归属的用户组、读写权限等。
inode为每个文件进行信息索引,所以就有了inode的数值。操作系统根据指令,能通过inode值最快的找到相对应的文件。
如果这台服务器的Block虽然还有剩余,但inode已经用满,在创建新目录或文件时,系统提示磁盘空间不足。
inode的数量是有限制的,每个文件对应一个Inode,那么如何查看inode的最大数量呢?
# df -i
可以看到,inode节点只用了小部分,依然不是问题的原因所在。
那么,是不是在此之前做过什么操作,可能造成了一些预期之外的后果?
此时想起,我曾经重新mount过数据盘,但是数据盘是独立的磁盘,照理说是不会占用根目录所在的系统盘空间。
实际上:如果mount目录下原来是有文件存在的,那么该目录被mount之后这些文件就会被隐藏,不属于该文件系统,使用du命令是看不到的!
停掉相关服务,验证一下:
# umount /opt
# ll /opt/
果然,发现/opt目录下有一个2.8G的文件,这个文件把根目录磁盘占满了!
问题原因找到了,应该是之前拷贝文件时,/opt 没有被mount,拷贝动作就将文件拷贝到了根目录,而重新mount数据盘之前没有检查该目录是否为空,导致了后来的根目录磁盘空间不足。
三、问题总结
如果mount目录下原来是有文件存在的,那么该目录被mount之后这些文件就会被隐藏,不属于该文件系统,使用du命令是看不到的!
在实际生产环境中,mount之前需要确认目录是否为空!
四、参考
Linux根目录空间不足
https://www.jianshu.com/p/0698336f5b8e
https://blog.csdn.net/xiao_wj/article/details/52875458
理解inode
http://www.ruanyifeng.com/blog/2011/12/inode.html
How To Resize ext3 Partitions Without Losing Data
https://www.howtoforge.com/linux_resizing_ext3_partitions
No space left on device – running out of inodes
https://www.ivankuznetsov.com/2010/02/no-space-left-on-device-running-out-of-inodes.html
https://unix.stackexchange.com/questions/396965/no-free-space-left-inode-shortage