我刚刚开始接触作为虚拟机运行的 Alpine Linux (v3.13.2)。 （在 Hyper-V 上，但我认为这在这里并不重要。）我想知道为什么安装后，Alpine Linux 似乎只使用预期的“0-700MB”，但在安装过程中它写入的内容足以使 .vhdx 文件增长到几乎 4GiB？
故事
我下载并使用“虚拟”.iso 安装到新的空白虚拟机中。我为驱动器创建了一个 127GiB、动态扩展的 vhdx；像往常一样，它以 4MiB .vhdx 文件开始。该虚拟机拥有 1GiB RAM、4 个 vCPU 和一个 NIC。在 期间setup-alpine，我几乎完全选择了默认值（除了键盘和时区、IIRC），但我以“sys”模式安装到“sda”。
在它实际创建文件系统时，.vhdx 文件一度从 4MiB 增长到约 1.7GiB，然后在我被告知重新启动时再次增长到约 3.5GiB。
卸载 .iso、重新启动并登录后，我终于看到了一个 3.72GiB 的 .vhdx 文件。但df表明我不是使用差不多那么多：
# df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 10240 0 10240 0% /dev
shm 505164 0 505164 0% /dev/shm
/dev/sda3 128048328 189800 121310972 0% /
tmpfs 101036 108 100928 0% /run
/dev/sda1 523248 272 522976 0% /boot/efi
它并不都是连续的“零”，因为我尝试执行我的常规Optimize-Vhd例程（Powershell），并且它并没有减少.vhdx的大小。我希望在Optimize-Vhd缩小 .vhdx 文件之前，我必须弄清楚如何在 Alpine Linux 实例中进行碎片整理。
想法？
答案1
它并不是 Alpine Linux 独有的东西。这是文件系统 (ext4) 的选项/行为以及 Windows 处理稀疏文件方式差异的一个因素。
Linux 依赖于稀疏文件，而 Windows 则不然，这意味着它通常会导致大量几乎完全空的块的扩展。我从你的读数中看到你使用了 32MB 的默认块大小，这通常会导致 Linux 使用的常见文件系统膨胀。并非所有 Linux 文件系统都这样做，因此您的磁盘可能会自然扩展。
Eric Siron 在 Technet 主题上发帖（2019 年 1 月 22 日星期二下午 5:46）。他有额外的 文章关于这个，谈论你什么时候可能想或不想担心它，以及如果你担心的话你会如何处理。
我接受了@Stewart 的建议进行尝试fstrim -v /，但虽然它报告说它修剪了~122GiB，但实际上并没有改变一些东西，以至于将Optimize-Vhd.vhdx 文件的大小缩小了~50MiB 以上。
基于另一条建议和Debian wiki 中的注释， 有一个很多discard对于该选项的实际作用以及它是好是坏的分歧/困惑。我敢打赌这部分与虚拟磁盘和物理磁盘之间的差异有关。由于fstrim没有帮助，我discard在尝试之前进行了全新安装并更改了 /etc/fstab 以使用该选项（并重新启动）fstrim。对于这种情况来说，这没有任何区别。
...fs 用于虚拟机，包含在主机上的稀疏原始映像文件中。如果分配新的块，随着时间的推移，随着文件的创建/删除/修改，映像文件会逐渐失去稀疏性，趋向于“非稀疏”大小，即使虚拟机上使用的总存储基本保持不变。
看来问题实际上更多的是文件系统不愿重新使用已删除的块。如果这是真的，那么我预计这种增长将停止在整个驱动器/vhdx 大小的一定百分比处。这对于我所看到的行为来说是有意义的（每次启动时 .vhdx 文件的大小都会增加约 30MiB，意思是：启动、登录、poweroff起泡、冲洗、重复；每次启动 +~30MiB。）。最后，我希望这是这种行为的结合和ext4 如何处理稀疏文件，而不是 Vhdx 驱动程序如何处理稀疏文件。
最后，我发现Microsoft 针对 Hyper-V 上的 Linux 的最佳实践。只需使用块大小为 1MB 的 vhdx，即可获得约 286MiB .vhdx 的全新安装！我没有费心去查看添加flex_bg=4096到 /etc/fstab 中的挂载选项是否会产生任何额外的差异。