這怎麼可能？

這一定是矩陣中的一個小故障。正確的？讓我解釋。

在將生成的原始圖像上傳到 S3 儲存桶（在 AWS 中）之前，我有一些自動化功能可以將 qcow2 圖像轉換為原始圖像。在周五之前，此自動化是專門為 RHEL qcow2 映像編寫的，但由於新的要求，該自動化已適應處理 BIGIP qcow2 映像。

直到今天，由於最初的自動化範圍有限，自動化還沒有一種機制來計算原始 qcow2 圖像的虛擬大小（例如，使用qemu-img info example.qcow2）。除此之外，當生成原始圖像時，一個簡單的ls -lth顯示它是 81GB：

-rw-r----- 1 d staff 81G Aug 7 01:52 f5-bigip-17.0u4.x86_64.raw

現在，如果寫在一個有足夠儲存空間來容納這種大小的文件的文件系統上，我不會想到任何事情。但是，在創建此文件之前，文件系統上只有大約 25GB 的可用空間：

[13662: 2022-0807 at 01:32:43: d@mac0 ~/Downloads]
$ df -h /
Filesystem     Size   Used  Avail Capacity iused               ifree %iused  Mounted on
/dev/disk1s1  932Gi  903Gi   25Gi    98% 5934135 9223372036848841672    0%   /

現在排隊的是，在創建原始圖像之後，儘管ls顯示了原始圖像的大小，但df顯示文件系統現在少了約 6GB：

[13664: 2022-0807 at 01:51:40: d@mac0 ~/Downloads]
$ df -h /
Filesystem     Size   Used  Avail Capacity iused               ifree %iused  Mounted on
/dev/disk1s1  932Gi  909Gi   19Gi    98% 5934638 9223372036848841169    0%   /

…因此，這就是源 qcow2 映像的磁碟大小：

# qemu-img info f5-bigip-17.0u4.x86_64.qcow2
image: f5-bigip-17.0u4.x86_64.qcow2
file format: qcow2
virtual size: 81G (86973087744 bytes)
disk size: 5.8G
cluster_size: 65536
Format specific information:
   compat: 0.10

到目前為止，我可以合理地說服自己，這種差異是如何存在的。唯一的問題是，由於自動化開始將原始圖像上傳到 S3 儲存桶，（在本文發佈時）它已經上傳了超過 55GB 的圖像：

1小時後上傳進度

有關執行此操作的系統的一些技術規範：

主機系統：Macbook Pro（/在加密的 APFS 卷上）

來賓系統：RHEL 7.4（通過 VMware Fusion v10）

qcow2 和原始圖像存在於主機系統的Downloads目錄中，與來賓系統共享/可從來賓系統訪問。

除非在這些文件所在的主機系統的文件系統上進行某種類型的壓縮和/或重複數據刪除，否則怎麼可能有一個 81GB 的文件寫入一個只有約 25GB 可用的文件系統，並且已經超過 55GB被複製到 S3 儲存桶？

感謝大家幫助回答這個問題。

~D

---

附加資訊：

回顧我在主機（即我的 MBP）上的終端會話中的一些輸出，我注意到當我解除安裝另外兩個原始圖像（一個 RHEL 7.9 圖像和一個 RHEL 8.4 圖像）時，每個 10GB（根據ls） ，我只獲得了~11GB，如下所示df：

[13658: 2022-0807 at 01:24:50: d@mac0 ~/Downloads]
$ df -h /
Filesystem     Size   Used  Avail Capacity iused               ifree %iused  Mounted on
/dev/disk1s1  932Gi  914Gi   14Gi    99% 5933944 9223372036848841863    0%   /
[13659: 2022-0807 at 01:26:44: d@mac0 ~/Downloads]
$ ls -ltr *.raw
-rw-------  1 d  staff  10737418240 Aug  9  2021 el-server-8.4.x86_64.raw
-rw-------  1 d  staff  10737418240 Jan 20  2022 el-server-7.9u3.x86_64.raw
[13661: 2022-0807 at 01:26:51: d@mac0 ~/Downloads]
$ time mv *.raw /Volumes/Elements/home/Downloads/

real    4m54.121s
user    0m5.227s
sys 0m38.865s
[13662: 2022-0807 at 01:32:43: d@mac0 ~/Downloads]
$ df -h /
Filesystem     Size   Used  Avail Capacity iused               ifree %iused  Mounted on
/dev/disk1s1  932Gi  903Gi   25Gi    98% 5934135 9223372036848841672    0%   /

除非您在創建 VM 時選擇了將所有磁碟空間預分配給 VM 的選項，否則創建的映像文件是稀疏文件。稀疏文件在只有零的地方不包含任何數據，它們只是包含一些指標，表明在這個地方應該有特定數量的零塊。因此，稀疏文件的實際大小可能遠小於目錄中指示的大小。

這是一篇關於稀疏文件的非常簡短的文章：https ://www.lisenet.com/2014/so-what-is-the-size-of-that-file/

引用自：https://serverfault.com/questions/1107626