大家好，我是石头哥。

题目你可能读不全(没事，俺也雷同)，特此补充拼音!

[yòu shuāng ruò zhuó]

又双叒叕

最近有读者遭遇本文一个神奇的问题，来征询我为什么。我看了下，如实长短常经典的坑，我在刚毕业那会也遭遇过，之前著述也共享过，此次重新整理剪辑下，再共享给大家。

不错指摘区说说，你有遭遇过这个坑吗?

difference-between-du-and-ls

知谈为什么会有上头的成果吗?什么又是稀疏文献?这篇著述将为你揭秘。

某天收到的自动告警短信或者邮件告诉我某机器上的磁盘满了，速即登录机器稽察。

其实，这皆应该定时巡检自动化处理的。

第一次出现该问题时， 我的处理神志是: 先删了 /tmp/ 目次， 优游出部分空间， 然后查验下几个常用的用户目次。

最终发现某就业A的日记文献(contentutil.log)占用了好几个十个大G，征询联系建立东谈主员后确定该日记文献不需要压缩备份， 可平直删除，于是 rm contentutil.log 之后就活泼地以为万事大吉了...

rm 文献后，磁盘空间就开释了吗?

关联词，大要xx天后，发现该机器磁盘又满了，惊呼奇怪咋这样快又满了。

皇冠hg86a

最终发现是前次 rm contentutil.log 后， 占用好几十大G的 contentutil.log 一直被就业A的程度大开了，rm 后空间并莫得开释。

rm 其实是删除该文献名到文献信得过保存到磁盘位置的聚会，此时该文献句柄还被就业A大开，因此对应的磁盘空间并莫得被系统回收。

其实不错相识为 GC 内部的援用计数， rm 只是减少了援用计数，并莫得信得过的进行开释，当援用计数为0的技艺，OS 内核才会开释空间，供其他程度使用。

是以当A程度罢手(文献句柄的援用计数会变为0)或者重启后，占用的存储空间才被开释(从某种程度上讲说明该就业一直很自如， 不错连气儿跑很久不出故障~ 含笑容)。

tip: 淌若不知谈具体程度或文献名的话：lsof | grep deleted，这样会查找扫数被删除的然则文献句柄莫得开释的文献和相应的程度，然后再kill掉程度或者重开赴度即可。

其后，白雇主奉告不错用修改文献内容的神志在无须重开赴度的情况下开释空间。

底下这个妙技，划要点：

echo 排列五色碟"" > filename.log 

前两天该问题又出现了，该就业A的日记文献(contentutil.log)占用了约7.6G。

应该对就业日记作念 log rotate。

这一次学灵敏了，平直用echo 'hello' > contentutil.log， 然后 df 阐明磁盘空间如实依然开释，心想着此次不错 Happy 了，倏得手贱奉行了下 ls 和 du， 有了以下成果:

[root@xxx shangtongdai-content-util]# ls -lah contentutil.log -rw-r--r--. 1 root root 7.6G Nov  7 19:36 contentutil.log [root@xxx shangtongdai-content-util]# du -h contentutil.log 2.3M    contentutil.log 

归正我看到这样的成果是百念念不得其解， 淌若你依然明确为什么会产生这样的成果呢?

不错明确的是， 这里的 ls 和 du 成果信托代表不同的含义，在查阅联系费事和防守弘大的票圈后了解到， 这好像与文献浮泛和稀疏文献(holes in 'sparse' files)联系.

ls 的成果是 apparent sizes， 我的相识是文献长度，就访佛文献系统中 file 这个数据结构中的界说文献长度的这个字段;

du 的成果 disk usage，即信得过占用存储空间的大小，且默许度量单元是 block。

皇冠客服飞机：@seo3687

apparent sizes 和 disk usage 说法摘自 man du 中的 --apparent-size 部分。

给出一个具体的示例:

// Mac OS 10.11.6 (15G1004) ➜  _drafts git:(source) ✗ echo -n a >1B.log ➜  _drafts git:(source) ✗ ls -las 1B.log 8 -rw-r--r--  1 tanglei  staff  1 11  9 00:06 1B.log ➜  _drafts git:(source) ✗ du 1B.log 8 1B.log ➜  _drafts git:(source) ✗ du -h 1B.log 4.0K 1B.log 

上头示例中， 文献 1B.log 内容只是包含一个字母"a"， 文献长度为1个字节， 前边的 8 为占用的存储空间 8 个 block， (ls -s 的成果跟 du 的成果等价， 皆是本体占用磁盘的空间)。

为什么1个字节的文献需要占用8个 block 呢， 不错这样相识， block 为磁盘存储的基本的单元，浅易磁盘寻址等(这里说的基本单元应该是磁盘物理结构单元举例一个扇区/柱面等，对应一个物理单元)。

而此处的block不错相识为一个逻辑单元， 且一个文献除了包括数据外， 还需要存储形容此文献的其他信息， 因此包含1个字节的文献本体在磁盘中占用的存储空间不啻1个字节。

这里借用最近超火的一篇著述的图示来证明：

以800万年前的野生大熊猫形象为原型创造的舞剧，是否会让观众耳目一新？

不得不说，欧博代理网址这篇 “0.2 秒真是复制了100G文献?” 著述这动丹青得真好，火是有原因的。不外，缺憾(调侃)的是最启动的原文竟然找不到了(后补充：源自奇伢云存储，聚会见指摘)，各个著述转载的技艺，皆没注原文。

磁盘文献科罚基本单元-block

然后读写的技艺，皆用另外一个结构来存储对应的 block 信息。

文献系统inode 和 block 区

默许情况下， Mac中1个逻辑 block 中是 512 字节， 因此 du -h 成果是 8 * 512 = 4096 = 4.0K.

If the environment variable BLOCKSIZE is set， and the -k option is not specified， the block counts will be displayed in units of that size block. If BLOCKSIZE is not set， and the -k option is not specified， the block counts will be displayed in 512-byte blocks. (man du)

因此， 不竭情况下， ls 的成果应该比 du 的成果更小(皆指用默许的参数奉行， 调治参数可使其抒发含义疏浚)， 关联词上头跑就业 A 的机器上 contentutil.log 的对比成果是 7.6G vs. 2.3M， 仍然无法相识了。

沿着 man du 不错看到:

although the apparent size is usually smaller， it may be larger due to holes in ('sparse') files， internal fragmentation， indirect blocks， and the like

即因contentutil.log是一个稀疏文献， 天然其文献长度很大， 到7.6G了， 关联词其中包含广博的holes并不占用本体的存储空间。

底下用一个具体的例子来复现以上遭遇的问题。留心以下例子为 Linux version 2.6.32 (Red Hat 4.4.7)中运行成果， 且在 Mac 中并不可复现(后文有指出为什么我的Mac不可复现)。

// 从设施输入中读取 count=0 个block， 输出到 sparse-file 中，  // 一个 block 的大小为1k(bs=1k)， 输出时先将写指针移动到 seek 位置的场地 [root@localhost ~]# dd of=sparse-file bs=1k seek=5120 count=0 0+0 records in 0+0 records out 0 bytes (0 B) copied， 1.6329e-05 s， 0.0 kB/s // 是以此时的文献长度为: 5M = 5120*1k(1024) = 5242880 [root@localhost ~]# ls -l sparse-file -rw-r--r--. 1 root root 5242880 Nov  8 11:32 sparse-file [root@localhost ~]# ls -ls sparse-file 0 -rw-r--r--. 1 root root 5242880 Nov  8 11:32 sparse-file // 而 sparse-file 占用的存储空间为 0 个 block [root@localhost ~]# du sparse-file 0 sparse-file [root@localhost ~]# du -h sparse-file 0 sparse-file 

此时若用 vim 大开该文献， 用二进制体式稽察 (tip :%!xxd 不错窜改现时文献裸露为2进制体式)， 能看到内部的内容全是0. 或者平直用od号召稽察2进制.

// vim 二进制稽察 0000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................ 0000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................ .... //od -b sparse-file 0000000   000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 * 24000000 

本体上， Sparse 文献是并不占用磁盘存储空间的， 那为什么能看到文献内部包含许多0? 因为当在读取稀疏文献的技艺， 文献系统证据文献的 metadata(等于前边所指形容文献的这个数据结构)自动用0填充[ref Wiki];

Wiki上还说，当代的不少文献系统皆复旧 Sparse 文献， 包括 Unix 偏激变种和 NTFS， 关联词Apple File System(APFS)不复旧， 因此我在我的 Mac 上用 du 稽察占用空间与 ls 的成果一致。

// In Mac ➜  ~ dd of=sparse-file bs=1k seek=5120 count=0 0+0 records in 0+0 records out 0 bytes transferred in 0.000024 secs (0 bytes/sec) ➜  ~ ls -ls sparse-file 10240 -rw-r--r--  1 tanglei  staff  5242880 11  9 09:44 sparse-file ➜  ~ du sparse-file 10240 sparse-file 

以上是用 dd 等号召创建稀疏文献， 也有同学用 c 代码达成了疏浚的功能。

其实等于写文献的技艺， 改变下现时文献写指针，前边遭遇的问题就应该访佛。

#include <stdio.h> #include <fcntl.h> #include <string.h>  int main() {     int fd， result;     char wbuf[] = "hello";      if ((fd = open("./filetest.log"， O_RDWR|O_CREAT|O_EXCL， S_IRUSR|S_IWUSR)) )  {             perror("open");             return -1;     }     if ((result = write(fd， wbuf， strlen(wbuf)+1)) < 0) {             perror("write");             return -1;     }     if ((result = lseek(fd， 1024*1024*10， SEEK_END)) < 0) {             perror("lseek");             return -1;     }     if ((result = write(fd， wbuf， strlen(wbuf)+1)) < 0) {             perror("write");             return -1;     }      close(fd);     return 0; } 

以上先将"hello"写入 filetest.log， 然后改变文献指针到1024*1024*10(尽头于文献长度这个字段变大了)， gcc 编译后运行成果文献笃定如下:

[root@localhost ~]# ls -ls filetest.log 8 -rw-------. 1 root root 10485772 Nov  9 17:45 filetest.log [root@localhost ~]# du  filetest.log 8 filetest.log [root@localhost ~]# du -h filetest.log 8.0K filetest.log [root@localhost ~]# ls -lh filetest.log -rw-------. 1 root root 11M Nov  9 17:45 filetest.log [root@localhost ~]# od -c filetest.log 0000000   h   e   l   l   o  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 0000020  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 * 50000000  \0  \0  \0  \0  \0  \0   h   e   l   l   o  \0 50000014 

证明下成果: 文献长度应该是 "hello" 加上 "\n" 共6个字节*2 = 12， 再加上1024*1024*10个字节， 即为ls产生的成果10485772个字知人善察11M。

而du的成果为8个block也为8k(这台机器上的block大小与前边的Mac不雷同， 这里是1024)。

Display values are in units of the first available SIZE from --block-size， and the DU_BLOCK_SIZE， BLOCK_SIZE and BLOCKSIZE environment variables. Otherwise， units default to 1024 bytes (or 512 if POSIXLY_CORRECT is set. (du --help)

回来一下: 出现以上问题说明我方对一些基础掌抓得尚不牢固， 比如

rm 某文献后， 文献占用的磁盘空间并不是立即开释，而是其句柄莫得被轻易一个程度援用时才回收;

ls/du 号召成果的具体含义;

稀疏文献。