虛擬機中的 ZFS
我應該在虛擬機中使用 ZFS 嗎？根據現有資訊（特別是這個執行緒，我將在下面引用）這不是一個好主意，除非提供某些措施（例如使用 VT-d）。據稱，基本問題是管理程序可能會報告要寫入的塊，而實際上它還沒有被寫入。據稱，與其他文件系統相比，ZFS 對這種差異特別敏感：
為什麼它如此糟糕的細節與它的 fsck-less 設計有關。
討論中還承認：
據我所知，“指針寫入數據之前”變成“指針寫入但沒有數據”的唯一情況仍然是作業系統或管理程序崩潰的事件。
但是如果發生這樣的崩潰，最壞的後果是什麼？
- 崩潰時寫入的文件損壞或失去？
- 數據集中的任何其他文件損壞或失去？
- 數據集中的任何文件損壞或失去，這些文件在崩潰時沒有被修改，例如，在崩潰之前很久拍攝的快照？
是否有任何可能的靜默損壞，無法通過擦洗檢測到？
我試圖通過使用 VirtualBox 並在將數據寫入 VM 內的 ZFS 時選擇關閉/關閉電源來模擬崩潰。我這樣做了大約 20 次，但沒有發現任何問題。也許這種測試方法不合適。有沒有更好的方法來試驗這個？
基本上任何現代管理程序（VMWare、Xen、KVM、HyperV，甚至 VirtualBox）都支持屏障傳遞：當 VM 顯式將某些內容刷新到磁碟（通過發出屏障/FUA）時，管理程序會將屏障向下傳遞給主機，從而強制來賓作業系統執行相同的刷新。換句話說，重要/持久寫入（文件系統本身用於更新其元數據的寫入）不會損壞。
雖然大多數虛擬機管理程序可以配置為忽略刷新，但這可能會危及任何文件系統 - XFS、EXT4 等將像 ZFS 一樣面臨嚴重的損壞。
回到主要問題：在客戶作業系統中使用 ZFS 是完全安全的，我對類似設置有第一手經驗。這將使客人能夠使用高級功能，如壓縮、快照和發送/接收。但是，這可能會導致客戶機性能有所降低（ZFS 並非設計為贏得基準測試的文件系統）。此外，由於許多 SAN 在磁碟映像級別實現了完全相同的功能，因此您應該評估雙 CoW 對性能的影響是否值得在客戶級別提供額外的靈活性。
由於上述原因，我通常在磁碟映像/管理程序級別使用 ZFS，而在虛擬機本身內部使用 XFS 或 EXT4。但是，在我無法查看底層 SAN/儲存（及其快照/壓縮/複製策略）的情況下，有時我會在客戶級別使用 ZFS。
在這些情況下，添加的功能不僅僅可以補償性能影響，例如，簡單的 XFS 設置。而且我根本沒有穩定性/耐用性問題。
旁注： VT-d 僅在您計劃將原始磁碟（或其他硬體設備）傳遞給來賓本身時才有用。如果使用基於文件或卷的虛擬磁碟，則沒有使用 VT-d。