linux du命令的疑惑

起因是测试rsync传输数据。传输完成后，想看一下传输的文件是不是完整，所以检测了下源目录和目标目录的大小，竟然出现了巨大的差距：

[root@w anaconda3]$ du -sh ./
2.9G    ./

以及

[root@test anaconda3]# du -sh ./
4.7G    ./

同样一个anaconda3目录，在新机器占用的磁盘大小竟然比源机器上多了将近2个G！！比原来的目录小还可以理解为传输问题，比原来的目录大就很奇怪了。

在去看看文件的数量是不是一致：

[root@w anaconda3]$ find ./ | wc -l
118596

[root@test anaconda3]$ find ./ | wc -l
118596

数量是一样的，更奇怪了，继续查看子目录大小：

[root@w anaconda3]$ ls| xargs -n 1 du -sh
139M    bin
2.0M    compiler_compat
4.1M    conda-meta
544K    doc
0    envs
40K    etc
56M    include
1.9G    lib
680K    libexec
8.0K    LICENSE.txt
52K    man
2.6M    mkspecs
320K    phrasebooks
2.6G    pkgs
4.2M    plugins
6.2M    qml
65M    share
4.7M    ssl
11M    translations
484K    var
4.0K    x86_64-conda_cos6-linux-gn

[root@test anaconda3]#  ls| xargs -n 1 du -sh
139M    bin
2.0M    compiler_compat
4.1M    conda-meta
540K    doc
0    envs
40K    etc
56M    include
1.8G    lib
676K    libexec
8.0K    LICENSE.txt
48K    man
2.5M    mkspecs
320K    phrasebooks
2.6G    pkgs
4.2M    plugins
6.2M    qml
65M    share
4.7M    ssl
11M    translations
484K    var
4.0K    x86_64-conda_cos6-linux-gnu

对比一下，发现差距并不大啊(⊙o⊙)…，这就有点奇怪了，从结果来看新机器上"du -sh ./"的结果应该是对的，应该是老机器上执行"du -sh ./"的结果有点问题。

所以关注的重点转移到老机器上的“du”命令。

根据google到的信息，主要集中在下面几点上：

1. du和ls的对比：du默认统计的是文件所占用的块的大小，操作系统分配磁盘空间是以块为单位，即使实际使用的空间不足一个块，别的文件也不能使用这个块空间。ls命令统计的是文件使用的实际空间。一般文件du命令的结果会比ls大一些，而特殊文件如“稀疏文件”，du的结果可能会小一些，这应该是和“稀疏文件”的存储方式有关。
2. du命令也可以统计实际空间，使用“-b”选项
3. du -sh ./* 和 du -sh ./ 结果可能不同，因为./*不会匹配隐藏文件，也就是“.name”以“.”开头的文件。同理du -sh * 和 du -sh 结果也可能不同
4. du和df的对比：如果某个文件被删除了，但依然有进程打开了它，那么df会计入这个文件，但du不会；稀疏文件也可能导致不同。

这几点都没有解释在老机器上运行du命令显示的奇怪结果，所以继续试试其他命令，包括列出每个文件的大小并加总等：

find ./ | xargs du -b | awk 'BEGIN {sum=0} ; {sum+=$1} END {print sum}'
find ./ -type l -o -type f| xargs du -b | awk 'BEGIN {sum=0} ; {sum+=$1} END {print sum}'
ls -l -R | awk 'BEGIN {sum=0} ; {sum+=$5} END {print sum}'
ls -a | xargs du -b | awk 'BEGIN {sum=0} ; {sum+=$1} END {print sum}'
find ./ -not -type d | xargs du  | awk 'BEGIN {sum=0} ; {sum+=$1} END {print sum}'
find ./ -not -type d | xargs ls -l | awk 'BEGIN {sum=0} ; {sum+=$5} END {print sum}'
ls | xargs -n 1 du -sb | awk 'BEGIN {sum=0} ; {sum+=$1} END {print sum}'
ll | grep -v ^d | awk 'BEGIN {sum=0} ; {sum+=$5} END {print sum}'
du -abhc ./ | wc -l

p.s. xargs命令默认是把所有参数一起放在命令行上传给程序，所以ls -a | xargs du -b的结果可能是du -b a.txt b.txt ...，而xargs -n 1di -b的结果是du -b a.txt；du -b b.txt等。

上面的命令仍然解释不了原因。

google上也提到过rsync传输后目录大小不一致的可能原因：

1. 硬链接。rsync默认会把2个硬链接文件复制成两个文件，磁盘占用空间就多了一个文件的大小。
2. 稀疏文件。rsync默认不会写这一类文件

检查了一番之后，似乎只有软连接，没什么硬链接。

最后没有办法，试了试VNC链接图形界面：

神奇的发现：这里的文件大小。。。也是不对的。(⊙o⊙)…

这。。。不知道怎么下手了，打算就此打住，姑且当做是一个bug吧。

另外，google上也提到了一个验证文件完整性的方法：通过checksum 校验和验证。

[root@w anaconda3]$  find . -type f ( -exec sha1sum "{}" ; ) | sort -k2,2 | sha1sum
ab15e4e01e363e69bf80d1d0aecdf101452f85d6  -

[root@test anaconda3]$  find . -type f ( -exec sha1sum "{}" ; ) | sort -k2,2 | sha1sum
ab15e4e01e363e69bf80d1d0aecdf101452f85d6 -

结果一致，但时间上会慢不少。