在修改时使用 fallocate --dig-holes 是否安全

Question

是吗安全的fallocate --dig-holes在文件被修改/写入时使用它？例如在 KVM 客户机打开的 QCOW2 映像上？

Answer 1

我一般会说不。如果文件是挂载到虚拟机的映像，您可以尝试 TRIM（例如 fstrim -a）。严格来说，这不是等效的（TRIM 还可以释放一些未归零的已删除文件的空间），但这可能是您想要的。

在某些特定情况下，它可能是安全的，但我不会依赖它。例如，当一些数据按顺序流式传输到文件时无需任何预先分配，这听起来可能是安全的。但由于文档中没有暗示这一点，而且它只依赖于实现，因此我强烈不推荐它。

可能出现什么问题？想象一下，应用程序/虚拟机将覆盖某个归零块，并且您同时运行 fallocate -d。竞争可能看起来像：

1. Fallocate 看到一块零，所以决定在那里挖一个洞。
2. 另一个应用程序/虚拟机向零块写入一些数据。
3. Fallocate 在区块上挖了一个洞。

听起来 1 和 3 之间似乎有一个小的时间范围。也许这是真的，但 fallocate 可能想要一次释放多个后续块。（不确定，我没有检查过实现，但即使相反的情况属实，您也不能依赖它。）这会增加 1 和 3 之间的延迟，使竞争条件更有可能发生。