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 -

結果一致，但時間上會慢不少。