为什么文件删除了但磁盘空间没有释放？
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
通过这种方法，磁盘空间不仅可以马上释放，也可以保证进程能够一直往文件里写数据