使用基于稀疏文件的 vdevs 进行 LVM 到 ZFS 迁移的潜在后果是什么？

Question

我一直在玩弄 ZFS，终于接受了它足够成熟我不应该被烧毁的事实。

现在迁移家庭 NAS 盒，它目前是一个 LVM JBOD 设置，它已经很满了，但我只有一个驱动器上有相当多的空间未分配。

我一直在使用在稀疏文件上创建的 zpools 来试验 zfs。用物理分区替换基于文件的 vdevs 似乎是一种非常灵活的前进方式。

我想知道如果我将这个想法发挥到极致，在这个已经非常完整的文件系统中创建与现有硬件相同大小的稀疏文件 vdev，并将内容从 LVM 移到 ZFS 阵列中，会发生什么.

理论上，只要 LVM 文件系统上的可用空间足以容纳不断增长的 ZFS，随着文件从其中删除，它就会继续运行。然后最终 LVM 文件系统将是空的，除了可以用物理分区替换的实际 ZFS 映像。

我预计至少会由于碎片化而对性能产生严重影响。

从表面上看，这听起来很疯狂，为什么要将文件复制到同一文件系统上的另一个容器中。所以我相信这个数据集将受益于打开重复数据删除和压缩，因此最终可能会有更多的可用空间。主要目标是获得将数据放在 ZFS 池中的灵活性，该池可以升级它的“驱动器”，即用物理硬件替换

这个疯狂的问题的灵感来自这篇关于使用环回设备作为临时硬盘更换来转换阵列的raid级别的博客文章。

Answer 1

将 zpool 作为文件放在现有文件系统上意味着您依赖该文件系统来提供一致性（这听起来很危险），而且 ZFS 不能很好地利用缓存。我不确定 ZFS 将如何处理从文件到物理设备的传输；文件系统本身可能不会有任何真正的抱怨，但是您可能会遇到诸如它不喜欢将 vdevs 安装到较小设备上的情况（根据我的阅读，很多人对此已经设置了一点autoexpand=on，所以您可能要小心处理该财产及其表亲autoreplace）。或者，您将在 LVM 之上运行 ZFS，这可能是可能的，但不允许 ZFS 智能地处理设备，因为它只会看到一个巨大的设备。请记住，ZFS不只是一个文件系统，这是一个卷管理器一样，所以适当地替换两个常规文件系统和LVM。当 ZFS 对物理存储布局有很好的了解时，它的许多功能（包括将元数据放置在多个磁盘上以及用于 zpool 中的冗余数据的多个副本）效果最佳。

我也一直在考虑迁移到 ZFS，我能够提出的迁移的最佳选择涉及多一个硬盘。安装另一个硬盘，该硬盘的大小至少与您当前在阵列中拥有的最小物理驱动器的大小相同，在其上创建 ZFS 池和文件系统（针对 JBOD 进行配置，但只有一个设备），然后将尽可能多的移动到它上面能够。（因为我没有运行 LVM，我会将最小驱动器上的所有内容都移到 ZFS fs 上。）通过从中移除一个物理磁盘来减少 LVM 阵列，将 ZFS zpool 扩展到该现在空闲的磁盘上，再移动一些文件，冲洗并重复直到完成。通过巧妙地使用符号链接或良好的导出处理，您甚至可以使过程对可能同时使用您的 NAS 盒上的文件的任何人保持透明。