既然文件数据都存储在 block 中，那么我们指定读取某个文件数据的时候，操作系统就需要知道这个文件存储在哪个 block 上

而文件的数据存放位置信息被存放到了 inode 上，inode 中文名叫索引节点

我要打开 1.txt 这个文件并读取内容，会经过以下步骤

1、系统根据文件名（1.txt）找到对应的 inode 号

2、通过 inode 号获取到 inode 信息

3、根据 inode 信息找到文件数据所在的 block ，读出数据

除了文件的数据存放信息，文件的创建者、文件的大小、文件的属性等文件的元信息都被存储到了 inode 上

文件元信息包含以下内容（可以通过 stat 命令查看）

• 文件的字节数

• 文件拥有者的 User ID

• 文件拥有者的 User ID

• 文件拥有者的 User ID

• 文件的时间戳

• 链接数，即有多少文件名指向这个inode

• 数据block的位置

inode 跟数据一样会消耗硬盘空间，所以硬盘格式化的时候，系统自动将硬盘分成2个区域：

• 一个是数据区，存放文件数据

• 另一个是 inode 区，存放 inode 所包含的信息，即文件元信息

简单来说在 Linux 下，文件由指针部分（inode）和数据部分（data）组成

在了解了文件的存储结构之后，我们来看下对文件执 rm 行删除操作之后，这两个部分会发生什么

文件被删除的时候，文件对应的 inode 就被删除掉了，而文件的数据部分在 inode 被清除掉之后，就会被覆盖并写入新的内容

但是如果文件在删除的时候是被打开的（有一个进程正在使用该文件，文件被进程锁定或者有进程一直在向这个文件写数据等）状态，那么进程依旧可以读取该文件，系统就会认为该文件的磁盘空间一直被占用

之所以出现删除 access_log 文件后空间没有释放，是因为 nginx 进程还在一直向这个文件写入内容

虽然删除了 access_log 文件，但是由于 nginx 进程锁定，文件的 inode 并没有清除掉，而由于 inode 没有清除，系统内核就认为文件并未删除，这才出现空间不释放的情况

解决问题

既然有了定位的思路，我们就来看看是不是有进程一直在向 access_log 文件写数据

我们使用 lsof 命令

可以看到 /var/log/nginx/access_log被进程 nginx 锁定，而且 nginx 进程一直在往这个文件写数据，现在文件大小已经 68G 了

由此可见，这个文件就是导致系统根目录空间耗尽的罪魁祸首，而最后一列的 deleted 状态表示这个文件已经被删除

但由于进程还在一直往里面写数据，导致磁盘空间并未释放

• 方法一

删除掉日志文件之后，重启 nginx 进程或者重启系统让操作系统来回收磁盘空间