一、问题背景

一台数据库服务器，突然监控告警，报根目录空间不足(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