rm -rf之后就高枕无忧了？

现在运营的平台采用的是微服务架构，部署的服务较多，开发环境一台服务器上部署几十个服务是很正常的，之前用CI构建部署的时候，发现磁盘满了。我的处理方式是：先删了 /tmp/ 目录, 空闲出部分空间，然后检查下几个常用的用户目录，发现几个日志文件占用了好几个大G，由于是开发环境，所以就直接删除, 于是 rm之后就天真地认为万事大吉了...

然而过几天后，又有同事发现该机器磁盘又满了，惊呼奇怪咋这么快又满了。最终发现是上次 rm后，占用好几个大G的日志文件被删除之后，磁盘空间并没有释放。rm 其实是删除该文件名到文件真正保存到磁盘位置的链接，此时该文件句柄还被服务打开，因此对应的数据并没有被回收，其实可以理解为 GC 里面的引用计数，rm 只是减少了引用计数，并没有真正的进行释放内存，当引用计数为0的时候，OS 内核才会释放空间，供其他进程使用。所以当服务进程停止(文件句柄的引用计数会变为0)或者重启后，占用的存储空间才被释放。如果不知道具体进程或文件名的话：lsof | grep deleted，这样会查找所有被删除的但是文件句柄没有释放的文件和相应的进程，然后再kill掉进程或者重启进程即可。

其实可以简单用修改文件内容的方式（例如echo "test">test.log）在不用重启进程的情况下释放空间。

du和ls的区别

对于某个日志文件，直接用echo "test" > yyzx_tradingcenterservice.log.2020-06-03.log，然后 df 确认磁盘空间确实已经释放，分别执行下面的命令：

[dev@tjptdebug-no yyzx_tradingcenterservice_logs]$ du -h  yyzx_tradingcenterservice.log.2020-06-03.log 
4.0K	yyzx_tradingcenterservice.log.2020-06-03.log
[dev@tjptdebug-no yyzx_tradingcenterservice_logs]$ ll -h  yyzx_tradingcenterservice.log.2020-06-03.log
-rw-rw-r-- 1 dev dev 7 Jul  8 19:49 yyzx_tradingcenterservice.log.2020-06-03.log

ls 的结果是 apparent sizes，我的理解是文件长度，就类似文件系统中 file 这个数据结构中的定义文件长度的这个字段，du 的结果 disk usage，即真正占用存储空间的大小，且默认度量单位是 block。block 为磁盘存储的基本的单位，方便磁盘寻址等(这里说的基本单位应该是磁盘物理结构单位例如一个扇区/柱面等, 对应一个物理单位)，而此处的block可以理解为一个逻辑单位，且一个文件除了包括数据外，还需要存储描述此文件的其他信息，因此包含1个字节的文件实际在磁盘中占用的存储空间不止1个字节。

总结

du == disk usage (磁盘使用量，占用的磁盘空间)
ls == apparent sizes(文件长度,file数据结构中定义的文件长度字段)
一个文件占用的磁盘空间和一个文件的大小是两码事情。占用空间取决于文件系统的块（block）的大小，Linux一般默认是4k(4096) ,因此，一个大小为1个字节的文件，最小也要占用4k,如果你创建文件系统的时候制定块大小是16K，那么即便一个文件只有1个字节，占用空间也是16K。通常情况下，ls 显示的文件大小比du显示的磁盘占用空间小，比如文件系统的block是4K，一个13K的文件占用的空间是 13k/4k = 3.25 个block，一个block只能被一个文件占用，因此实际占用空间就是4个block，就是16K。