Linux 系统inode耗尽导致应用故障

1 ． 错误现象

客户的一台 Oracle 数据库服务器，在关机重启后，oracle 监听无法启动，提示错误如图所示，inode 耗尽故障现象。

 

从输出信息判断，应该是磁盘空间耗尽导致 Oracle 监听无法启动，因为 Oracle 在启动监听时需要创建监听日志文件，而上面三个 TNS 错误产生的原因都是由最后一行错误导致的，于是首先检查系统磁盘空间，如图所示。查看故障服务器磁盘空间信息。

 

从磁盘输出信息可知，所有分区磁盘空间都还有不少剩余，而 oracle 监听写日志的路径在/var 分区下，虽然/var 分区仅剩下 3.2GB 可用磁盘空间，但是这对于写一个监听日志文件来说足够了，为什么还提示空间不足呢？

2 ． 解决思路

既然错误提示与磁盘空间有关，那就深入研究下关于磁盘空间的问题，在 Linux 系统中对磁盘空间的占用分为三个部分：第一个是物理磁盘空间，第二个是 inode 节点所占用的磁盘空间，第三个是 Linux 用来存放信号量的空间，而平时接触较多的是物理磁盘空间，对第二个和第三个空间的问题接触较少。既然不是物理磁盘空间的问题，接着检查是否是 inode节点耗尽的问题，通过执行“df -i”查看系统可用的 inode 节点，如图所示。查看磁盘分区的 inode 使用信息。

 

由输出可知，果然是 inode 节点耗尽导致无法写日志文件。由于 inode 全部被用完了，虽然还有可用磁盘空间，但是文件系统已经无法再记录这些空余空间了，因此也就不能再创建新文件或文件夹了。由于涉及了 inode 知识，接下来就简单介绍下 Linux 中 inode 的概念。在 Linux 系统中，文件由数据块和元数据组成，数据块就是多个连续性的扇区，是文件存取的最小单位。 “块（block）”的大小，最常见的是 4KB，即连续八个 sector 组成一个 block。而元数据用来记录文件的创建者、文件的创建日期、文件的大小等，这种储存文件元数据信息的区域就叫做 inode，或者称为“索引节点”。

由于 inode 也是用来存储文件相关属性信息的，因此 inode 也会消耗硬盘空间，在硬盘格式化的时候，操作系统会自动将硬盘分成两个区域。一个是数据区，存放文件数据；另一个是 inode 区（inode table），存放 inode 所包含的信息。

每个 inode 节点的大小，一般是 128 字节或 256 字节。inode 节点的总数在格式化文件系统的时候，就已经确定，可以通过如下命令查看某个磁盘分区 inode 的总数：

[root@localhost ~]# dumpe2fs -h /dev/sda3|grep 'Inode count'

dumpe2fs 1.39 (29-May-2019)

Inode count: 5244736

举个形象的例子，如果将文件系统比作一本书，那么，inode 就是这本书的目录。在格式化文件系统的时候，这本书的最大目录数已经确定了。在写书（保存文件到磁盘）的过程中，可能发生这样的情况：纸用完了（磁盘空间不足），此时肯定无法保存新的文件；但是还存在另外一种情况，就是目录写完了（inode 节点全部分配完了），在这种情况下，虽然还有纸（磁盘空间），但是目录（inode）已经没有了，在文件系统上当然不能新建文件了，因为没有了目录，文件就无法通过索引找到。

另外，每个 inode 都有一个号码，操作系统用 inode 号码来区分不同的文件。通过“ls -i”命令，可以查看文件名对应的 inode 号，例如：

[root@localhost ~]# ls -i install.log

325762 install.log

如果要查看这个文件更详细的 inode 信息，可以通过 stat 命令实现，如图所示。查看某文件 inode 的详细信息。

 

3 ． 解决问题

知道了产生这个故障是 inode 导致的后，接下来就要查看/var 目录下为何耗尽了 inode，通过检查发现/var/spool/clientmqueue/这个目录里面的文件仅 500 多万个，至于产生的原因，分析后确定应该是系统的 crontab 导致的，因为系统开了多个 crontab 任务，而如果 crontab任务没有重定向，默认就会在这个目录下创建一个文件，日积月累，此目录下的小文件就会超多。解决的方法很简单，删除这些没用的文件即可删除的方法是直接使用 rm 命令，这时肯定会提示“Argument list too long”的错误，而解决这个的方法上面章节已经有过详细介绍，通过如下命令即可完成：

[root@localhost ~]# find /var/spool/clientmqueue/ -name "*" -exec rm -rf {} \;

删除日志文件后，再次启动 Oracle 监听，可以顺利实现启动，查看新的监听日志文件已经生成，至此，问题得到圆满解决。