很久以前，我们买了Adaptec 31605的印象是：a）它可以做到真正的JBOD，b）它在OpenSolaris上得到很好的支持。 原来这两个都是不正确的。 我试图将我的zpool放到NexentaStor Enterprise操作系统上，但是要做到这一点，他们希望我们用LSI SAS 9201-16i交换控制器。
我试图找出廉价迁移池的最佳方法。 当前zpool使用14个SAS驱动器大约1TB。 我能想到的最好的是：
我在这里错过的任何东西或更好的方法的想法呢？
如果我走了这条路线，我应该等待多久？ 我的初步计算告诉我，1TB将花费大约3个小时以100MBps传输。 使用消费级驱动器上的zfs send / recv可以获得这种吞吐量吗？
你的计划看起来不错，我想你不会有任何麻烦。 你提到了三个1TB磁盘作为临时池。 我假设你打算使用单奇偶校验raidz（2TB可用），但我build议你考虑一个1.5或2TB磁盘镜像对。 这样当迁移完成时，每个磁盘都有一个池的完整备份。 在发生灾难性故障的情况下，适合投掷保险箱。 至于速度，我在两个2TB SATA磁盘的镜像池上得到了90-130MB /秒，所以你的3小时/ TB数字（〜100MB / sec）听起来是合理的。 如果你像我一样偏执，你可能还想刷新临时池，然后重新格式化SAS磁盘。
一旦你切换到让ZFS处理整个磁盘没有一层控制器抽象草真的是更绿色。 您可以将多个控制器的性能与相同的磁盘进行比较，如果硬件发生故障，甚至可以将磁盘连接到新系统。 我甚至使用原始设备映射临时将一个zfs池导入VMWare ESXi下的一个虚拟机，没有废话它只是工作。
恕我直言，在某些情况下这可能是可能的（不知道如何不同的控制器处理相同的磁盘）：
无论如何，您的build议要安全得多，因为在迁移结束之前，您始终拥有两份数据副本。
不知道这是否可以帮助你，但也考虑增量zfs发送。
通过这种方法，您可以拆分服务停机时间，让您在系统联机时执行第一个大而慢的zfs发送（SAS – > SATA）。
你的解决scheme好听。 如果您喜欢通过手动ZFS发送，则可以使用Nexenta的“自动同步”部分。