为什么文件删除了但磁盘空间没有释放？

1.案例现象

这天，监控系统发来一条告警消息，内容说某台服务器根目录磁盘占用空间达到阈值，超过百分之八十了

登上服务器，df -Th 看一下，发现磁盘空间确实不够用了

[root@localhost ~]# df -Th
文件系统                类型      容量  已用  可用  已用% 挂载点
...
/dev/mapper/centos-root xfs    100G  82G   18G   82%  /
...

进入到根目录，然后 du -sh *

[root@localhost /]# du -sh *
...
75G    var
...

可以看到，var 目录下的磁盘空间已经占用了 75G

既然如此，删除 var 目录下一些占空间较大的数据文件即可

#检查 /var 目录下占用空间前三的文件
[root@localhost /]# du -sm /var/* | sort -nr | head -n 3

继续定位到占用空间较大的是 /var/log 目录

最后排查到 /var/log/nginx/access_log这个文件占了 66G

这个文件是 Nginx 产生的访问日志文件，从日志大小来看，一方面没有做日志切割，另一方面很久没有清理这个文件

基本能够判断是这个文件造成的告警，执行如下删除操作

[root@localhost ~]# rm /var/log/nginx/access_log

删除完毕，我们再看下系统磁盘空间

[root@localhost ~]# df -Th
文件系统                类型      容量  已用  可用  已用% 挂载点
...
/dev/mapper/centos-root xfs    100G  82G   18G   82%  /
...

咦？根分区空间怎么还没有释放，不是删除了文件了吗？

2.定位问题

一般来讲，很少出现删除了文件但磁盘空间不释放的现象

但是如果出现了，就要考虑到以下两种情况：

文件被某一进程锁定了
有进程一直在向这个文件写数据

为什么文件被进程占用之后删除不会释放磁盘空间呢？

我们来学习一下 Linux 的文件存储结构

在 Linux 中，文件存储在硬盘上，硬盘的最小存储单位是扇区（Sector），然而扇区只有 512字节大小，如果每次都读写这么小的单位效率一定很低

所以当操作系统从硬盘读取数据的时候，不会一个个扇区的地去读取，而是一次性连续读取多个扇区，即一次性读取一个”块“（block）

由多个 sector 组成的 block ，是文件存取的最小单位

block 常见大小的是 4KB，即连续 8 个 sector 组成一个 block

既然文件数据都存储在 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 没有清除，系统内核就认为文件并未删除，这才出现空间不释放的情况

3.解决问题

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

我们使用 lsof 命令

#过滤出被程序占用但是已经删除的文件
[root@localhost ~]# lsof | grep deleted | grep access_log
[root@localhost /opt/em-oversea-sqlbridge]# lsof | grep deleted
nginx      766        nginx    3w      REG              253,0         0   68866960384 /var/log/nginx/access_log (deleted)

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

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

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

方法一

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

nginx -s reload

但是在生产环境下一般不建议重启服务或者重启系统

万一出问题了，这个锅可背不起

方法二（推荐）

像这种进程不停对文件写数据的操作，如果你想要清空磁盘空间，推荐的办法是在线清空这个文件

echo " " > /var/log/nginx/access_log
或者
cat /dev/null > /var/log/nginx/access_log

通过这种方法，磁盘空间不仅可以马上释放，也可以保证进程能够一直往文件里写数据