☰

这怎么可能呢？

tag-icon • tag-icon qemu qcow2
这怎么可能呢？

这必须可能是黑客帝国中的一个小故障。对吧？让我解释一下。

我有一些自动化功能，可以将 qcow2 图像转换为原始图像，然后再将生成的原始图像上传到 S3 存储桶（在 AWS 中）。周五之前，此自动化功能是专门为 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%   /

答案1

除非您在创建虚拟机时选择了将所有磁盘空间预先分配给虚拟机的选项，否则创建的映像文件将是疏文件。稀疏文件在只有零的地方不包含任何数据，它们只包含一些指示，表明此处应该有特定数量的零块。因此，稀疏文件的实际大小可能远小于目录中指示的大小。

这是一篇关于稀疏文件的非常简短的文章：https://www.lisenet.com/2014/so-what-is-the-size-of-that-file/

相关内容