使用基於稀疏文件的 vdev 進行 LVM 到 ZFS 遷移的潛在後果是什麼？
我一直在玩 ZFS，終於接受了它已經足夠成熟，我不應該被燒毀。
現在要遷移家庭 NAS 盒，它目前是一個 LVM JBOD 設置，已經很滿了，但我只有一個驅動器上有相當多的空間未分配。
我一直在使用在稀疏文件上創建的 zpool 來試驗 zfs。用物理分區替換基於文件的 vdev 似乎是一種非常靈活的前進方式。
我想知道如果我將這個想法發揮到極致，在這個已經非常完整的文件系統中創建與現有硬體大小相同的稀疏文件 vdev，並將內容從 LVM 移到 ZFS 數組中，會發生什麼.
理論上，只要 LVM 文件系統上的可用空間足以容納不斷增長的 ZFS，隨著文件被從中刪除，它就應該繼續執行。然後，除了可以用物理分區替換的實際 ZFS 映像之外，LVM 文件系統最終將是空的。
我預計至少會由於碎片化而對性能產生嚴重影響。
從表面上看，這聽起來很瘋狂，為什麼要將文件複製到同一文件系統上的另一個容器中。所以我相信這個數據集將受益於打開重複數據刪除和壓縮，因此最終可能會獲得更多的可用空間。主要目標是獲得將數據放在 ZFS 池中的靈活性，該池可以升級其“驅動器”，即用物理硬體替換
這個瘋狂的問題的靈感來自這篇關於使用環回設備作為臨時硬碟替代品來轉換陣列的 RAID 級別的部落格文章。
將您的 zpool 作為文件放在現有文件系統上意味著您依賴該文件系統來提供一致性（這聽起來很危險），而且 ZFS 不能很好地利用記憶體。我不確定 ZFS 將如何處理從文件到物理設備的傳輸；文件系統本身可能不會有任何真正的抱怨，但是您可能會遇到類似它不喜歡 vdev 進入較小設備的情況（根據我所讀到的，很多人已經被這個設置所困擾
autoexpand=on，所以您可能要小心該屬性及其表親autoreplace）。或者，您將在 LVM 之上執行 ZFS，這可能是可能的，但不允許 ZFS 智能地處理設備，因為它只會看到一個巨大的設備。請記住，ZFS 不僅僅是一個文件系統，它也是一個捲管理器，因此可以正確地替換正常文件系統和 LVM。當 ZFS 對物理儲存佈局有很好的了解時，它的許多功能（包括在多個磁碟上放置元數據和在 zpool 中為冗餘提供多個數據副本）工作得最好。我也一直在考慮遷移到 ZFS，而我能想到的遷移的最佳選擇是多加一個硬碟。安裝另一個硬碟，其大小至少與您目前在陣列中擁有的最小物理驅動器一樣大，在其上創建一個 ZFS 池和文件系統（為 JBOD 配置，但只有一個設備），然後儘可能多地移動到它上面能夠。（因為我沒有執行 LVM，所以我會將最小驅動器上的所有內容移動到 ZFS fs 上。）通過從中刪除一個物理磁碟來減少 LVM 陣列，將 ZFS zpool 擴展到該現在空閒的磁碟上，再移動一些文件，沖洗並重複直到完成。通過巧妙地使用符號連結或對導出進行良好處理，您甚至可以讓任何可能同時在您的 NAS 盒上使用文件的人保持該過程透明。