该牌坊维基建议使用BTFS当上了目录禁用的图像具有写入时复制。我确实看到如果您有很多文件读/写，那将是一个好主意。 这个问题探讨了这个想法。我知道 VMWare 会成长为不同的文件，并且会写出快照，这在使用 Copy-On-Write 时可能会出现问题。
对于 QEMU，该文件对于 VM 的存在保持打开状态，因此在 VM 关闭后写入存在潜在问题，但我会看到 VM 关闭后 I/O 缓慢不是问题。通过为 QEMU 执行此步骤，我将避免哪些陷阱。
另外：我假设这个问题的图像是原始的。由于 qcow2 已经具有 copy-on write，是否存在可能的稳定性问题。
BTRFS 上 VM 映像的性能下降不仅仅是由于大量文件写入；就 BTRFS 而言，写入是对同一个文件的。该问题源于对同一文件的大量随机写入。这些是在整个文件中发生的写入。
简而言之，随机写入会干扰 BTRFS 的 COW，导致文件碎片化，进而导致读取性能下降。如果您手头有图像文件，您可以使用filefrag.
请注意，这不仅仅是 VM 映像的问题。它会影响以随机文件偏移量写入的任何文件，例如 Firefox 使用的 SQLite 数据库。
关于 BTRFS 上的文件碎片，您可以做一些事情。选择以下选项之一：
nodatacow，这会在整个文件系统中禁用 COW。尽管实际上，它避免使用 COW，除非绝对必须（例如创建快照）。chattr在包含相关文件的目录上禁用 COW，然后重新创建文件，因为chattr不适用于现有文件。btrfs fi defrag针对有问题的文件运行。autodefrag以自动对文件系统进行碎片整理。前两个选项禁用COW，而后两个选项允许 COW 但事后清理。BTRFS COW 和 QEMU COW 不应该干扰，它只是特别慢:)
根据我对 SQLite 数据库文件的经验......
nodatacow - 没试过。chattr - 无论如何，我最终得到了碎片化的文件。btrfs fi defrag - 我做了一段时间来测试这个概念。autodefrag - 我一直在非常成功地使用它。对于 QEMU 映像，我使用 LVM 卷而不是映像文件。所以我根本不处理 COW 问题。
推荐阅读以更好地了解 COW 如何在 BTRFS 上工作。