linux系统删除文件后，可用率没变，磁盘还是满的

前言

某天更新服务时，发现服务怎么也上传不了，原因是磁盘空间不足，这很简单，直接找到大文件删除rm -rf 即可，但是我删除之后，df -h 发现磁盘空间一点变化都没有，可用率还是满的

排查

随后进行问题排查

难道是系统反应慢，没有刷新造成的？

我就立即执行

lecho 3 > /proc/sys/vm/drop_caches

这个命令会强制释放系统缓存空间，清空所有级别的缓存，包括页面缓存、dentry缓存和inode缓存

但是没什么用。。。。。

于是百度了示意

在 Linux 中，文件存储在硬盘上的最小存储单位是扇区（Sector），每个 sector 只有 512字节大小；多个 sector 可以组成文件块 （block） 。当我们读取某个文件数据的时候，操作系统就需要知道这个文件存储在哪个 block 上。文件的数据存放位置信息被存放到了 inode （索引节点）上。也就是说，在 Linux 下，文件由指针部分（inode）和数据部分（data）组成。

因此，执行 rm xxx 命令删除文件的时候，只是删掉了inode数据，而文件的实际数据部分在 inode 被清除掉之后，会被覆盖并写入新的内容。但是如果文件在删除的时候是被打开的（有一个进程正在使用该文件，文件被进程锁定或者有进程一直在向这个文件写数据等）状态，那么进程依旧可以读取该文件，系统就会认为该文件的磁盘空间一直被占用。

虽然删除了文件，但是由于进程还在一直向这个文件写入内容，文件的 inode 并没有清除掉，系统内核认为文件并未删除，这才出现空间不释放的情况。也就是说：当一个进程持续的写入一个文件的时候，直接删除这个文件，磁盘空间并不会得到释放。

那么我们就清楚了，是被占用导致表象删除，所以我们可以重启相关服务，或者是直接杀死该进程

解决

lsof | grep deleted | grep docker

我是docker相关服务引发的，所以我检索了docker，各位在不清楚的时候可以不用检索，直接lsof | grep deleted

于是我将这个进程kill -9 进程号

df- h

这样就正常了