因為我顯然在這裡遺漏了一些東西：
$ cp -a CENTOS-chroot 1
$ cp -a CENTOS-chroot 2
$ cp -a CENTOS-chroot 3
$ cp -a CENTOS-chroot 4
$ du --block-size=1 -s 1 2 3 4
6320304128 1
6320304128 2
6320234496 3
6320238592 4
我擁有的兩台 Linux 機器（Manjaro 和 Centos7）上的 HDD 和帶有 ext4 的 NVME SSD 都會發生這種情況。
答案1
不要忘記du在原始底層檔案系統層級報告磁碟使用情況，而不是在明顯的“文件大小「水平……看吧--apparent-size。
--apparent-size列印表觀大小，而不是磁碟使用；雖然表觀大小通常較小，但由於（「稀疏」）檔案中的漏洞、內部碎片、間接區塊等，它可能會更大
另請參閱-b，這可能是給予的更好選擇--block-size=1 和 --apparent-size一起：
-b,--bytes相當於
--apparent-size --block-size=1
……那麼，會du -bs ${dir}產生更好的結果嗎？
鑑於大多數/所有檔案系統都基於固定大小的區塊，因此很常見看到明顯的“文件大小「（即您可以從檔案中讀取的位元組數）與磁碟上實際使用的空間（即：儲存該檔案及其元資料所消耗的位元組數）不同。
例如：
- 小檔案通常會使用比它們更多的空間“應該「...在具有 4KiB 區塊的檔案系統上，檔案不可能使用少於 4KiB 的磁碟空間，即使它只儲存一個位元組。
- 大文件通常由許多“範圍「...範圍將描述在哪裡定位檔案的一部分的資料。範圍也消耗磁碟空間。
- 在沒有任何碎片（即：未使用空間的大間隙）的檔案系統中，可能有一個“大的" 文件只有一個範圍。
- 在具有大量碎片的檔案系統中（即：大量資料遍布各處，資料之間留有小間隙），同樣的“大的" 文件實際上可能有多個範圍，用於指示資料的儲存位置。
這完全取決於檔案在磁碟上的放置順序以及用於查找連續可用空間區塊的演算法。
您可以擁有一個非常節省空間的文件系統，它可以連續而仔細地重新排列所有文件，使它們像玩得很好的俄羅斯方塊一樣完美地鑲嵌。文件系統最終將花費大量時間來搜尋合適的空間，並且效能將受到嚴重影響。
同樣，您可以擁有一個非常面向碎片的檔案系統，它只使用第一個未使用的區塊，並跳過已使用的區塊。第一次寫入資料也會降低你的表現。
相反，我們更喜歡平衡事物，花錢一些時間 （但不要太多）來尋找一個連續的未使用空間區塊，其中將包含我們嘗試寫入的全部資料。
文件的碎片級別並不直接與複製命令的發出順序相關 - 部分原因是“嘗試一下，但不要太難”上述方法。
綜上所述，這兩個目錄中儲存的資料應該是相同的，但是磁碟使用情況（甚至對於相同的數據) 不太可能完美匹配。
有許多選項可以驗證儲存的資料是否相同 - 嘗試diff（沒有輸出是好的，它會報告更改）：
diff -qr "${src}" "${dst}"
更複雜的是，稀疏檔案可以使用顯著地低於預期：
$ truncate -s 100M x
$ ls -l x
-rw-r--r-- 1 attie attie 104857600 Jul 14 17:15 x
$ du --block-size 1 x
0 x
$ du -bs x
104857600 x
答案2
ext4 檔案系統的區塊和磁碟區佈局取決於檔案系統的填滿率和碎片。
這意味著，與空檔案系統相比，包含更多檔案的檔案系統可能會為其他檔案使用（略有）不同的空間。就您而言，第四個副本將比第一個副本佔用更多空間。