现在运营的平台采用的是微服务架构，部署的服务较多，开发环境一台服务器上部署几十个服务是很正常的，之前用CI构建部署的时候，发现磁盘满了。我的处理方式是：先删了 /tmp/ 目录, 空闲出部分空间，然后检查下几个常用的用户目录，发现几个日志文件占用了好几个大G，由于是开发环境，所以就直接删除, 于是 rm之后就天真地认为万事大吉了...
然而过几天后，又有同事发现该机器磁盘又满了，惊呼奇怪咋这么快又满了。最终发现是上次 rm后，占用好几个大G的日志文件被删除之后，磁盘空间并没有释放。Linux系统中是通过link的数量来控制文件删除的，只有当一个文件不存在任何link的时候，这个文件才会被删除。一般来说，每个文件都有2个link计数器:i_count 和 i_nlink，也就是说：Linux系统中只有i_nlink及i_count都为0的时候，这个文件才会真正被删除。
可以理解为i_count是内存引用计数器，i_nlink是磁盘的引用计数器。 当一个文件被某一个进程引用时，对应i_count数就会增加；当创建文件的硬链接的时候，对应i_nlink数就会增加。在Linux或者Unix系统中，通过rm或者文件管理器删除文件，只是将它会从文件系统的目录结构上解除链接(unlink)，实际上就是减少磁盘引用计数i_nlink，但是并不会减少i_count数。如果一个文件正在被某个进程调用，用户使用rm命令把文件"删除"了，这时候通过ls等文件管理命令就无法找到这个文件了，但是并不意味着这个文件真正的从磁盘上删除了。因为还有一个进程在正常的执行，在向文件中读取或写入，也就是说文件其实并没有被真正的"删除"，所以磁盘空间也就会一直被占用。当服务进程停止(文件句柄的引用计数会变为0)或者重启后，占用的存储空间才被释放。如果不知道具体进程或文件名的话：lsof | grep deleted，这样会查找所有被删除的但是文件句柄没有释放的文件和相应的进程，然后再kill掉进程或者重启进程即可。
其实可以简单用修改文件内容的方式（例如echo "test">test.log）在不用重启进程的情况下释放空间。
对于某个日志文件，直接用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。
