我应该在虚拟机中使用 ZFS 吗？根据现有信息（特别是此主题（我将在下面引用）这不是一个好主意，除非提供某些措施（例如使用 VT-d）。据称，基本问题是虚拟机管理程序可能会报告要写入的块，而实际上尚未写入。据称，与其他文件系统相比，ZFS 对这种差异特别敏感：
它为什么如此糟糕，具体原因与它没有 fsck 的设计有关。
该讨论还承认：
据我所知，“指针在数据之前写入”变成“指针已写入但没有数据”的唯一情况仍然是操作系统或虚拟机管理程序崩溃的情况。
但如果发生这样的事故，最坏的后果是什么呢？
- 崩溃时写入的文件是否损坏或丢失？
- 数据集中的任何其他文件是否损坏或丢失？
- 崩溃时未被修改的数据集中的任何文件是否损坏或丢失，例如崩溃前很久拍摄的快照？
是否存在任何可能被清理人员无法检测到的静默损坏？
我曾尝试使用 VirtualBox 模拟崩溃，并在将数据写入虚拟机内的 ZFS 时选择“关闭/关机”。我这样做了大约 20 次，但没有发现任何问题。也许这种测试方法不合适。有没有更好的方法来试验这个？
答案1
基本上，任何现代虚拟机管理程序（VMWare、Xen、KVM、HyperV，甚至 VirtualBox）都支持屏障传递：当虚拟机明确将某些内容刷新到磁盘时（通过发出屏障/FUA），虚拟机管理程序会将屏障传递到主机，强制客户操作系统执行相同的刷新。换句话说，重要/持久写入（如文件系统本身用于更新其元数据的写入）不会发生损坏。
虽然大多数虚拟机管理程序可以配置为忽略刷新，但这可能会危及任何文件系统 - XFS、EXT4 等将与 ZFS 一样面临严重损坏的风险。
回到主要问题：在客户操作系统中使用 ZFS 是绝对安全的，而且我有类似设置的第一手经验。这将使客户能够使用压缩、快照和发送/接收等高级功能。然而，这可能会导致客户性能略有降低（ZFS 并非设计为基准测试获胜的文件系统）。此外，由于许多 SAN 在磁盘映像级别实现了完全相同的功能，因此您应该评估双 CoW 造成的性能影响是否值得在客户级别增加灵活性。
出于上述原因，我通常在磁盘映像/虚拟机管理程序级别使用 ZFS，而在虚拟机内部使用 XFS 或 EXT4。但是，在无法查看底层 SAN/存储（及其快照/压缩/复制策略）的情况下，我有时会在客户机级别使用 ZFS。
在这些情况下，与普通的 XFS 设置相比，添加的功能足以弥补性能影响。而且我完全没有遇到稳定性/耐用性问题。
边注：VT-d 仅在您计划将原始磁盘（或其他硬件设备）传递给客户机本身时才有用。如果使用基于文件或卷的虚拟磁盘，则不使用 VT-d。