我一直在尝试 ZFS，最终承认它已经足够成熟，我不应该被烧毁。
现在要迁移家庭 NAS 盒，该盒目前是 LVM JBOD 设置，已满，但我在一个驱动器上有相当多的未分配空间。
我一直在使用在稀疏文件上创建的 zpool 来尝试 zfs。用物理分区替换基于文件的虚拟设备似乎是一种非常灵活的方法。
我想知道如果我将这个想法发挥到极致，并在这个已经非常满的文件系统中创建与现有硬件大小相同的稀疏文件 vdev，并将内容从 LVM 移至 ZFS 阵列，会发生什么。
理论上，只要 LVM 文件系统上的可用空间足以容纳不断增长的 ZFS，当文件从中删除时，它就应该继续运行。然后，除了实际的 ZFS 映像之外，LVM 文件系统最终将是空的，可以用物理分区替换。
我预计碎片至少会对性能产生严重影响。
从表面上看，这听起来完全疯狂，为什么要将文件复制到同一文件系统上的另一个容器中。因此，我相信该数据集将受益于重复数据删除和压缩的切换，因此最终可能会获得更多的可用空间。不过，主要目标是获得将数据存储在 ZFS 池中的灵活性，该池可以升级其“驱动器”，即替换为物理硬件
这个疯狂问题的灵感来自这篇博文使用环回设备作为临时硬盘替换来转换阵列的 raid 级别。
答案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 盒上的文件的任何人保持透明。