chr*_*ris 16 zfs storage-area-network
大多数关于ZFS 的讨论都建议关闭硬件 RAID，ZFS 应该直接与磁盘对话并管理主机（而不是 RAID 控制器）上的 RAID。
这在具有 2-16 个甚至更多本地磁盘的计算机上是有意义的，但是在具有大型 SAN 的环境中呢？
例如，我工作的企业有一个中等大小的 SAN，有 2 个完整的磁盘机架，大约有 400 个轴。我见过比我们更密集的 SAN 机架，以及比我们更大的 SAN 部署。
人们是否将 100 个磁盘直接暴露给大型 ZFS 服务器？300盘？3000盘？SAN 管理工具是否有助于此类事情的自动化管理？
FWIW 我在单个 ZFS 池中拥有最多92 个磁盘的经验，到目前为止它工作正常。
但是，如果您真的在谈论数百个磁盘，我会考虑将它们划分为少量分离（但仍然很大）的池。我不想知道zpool scrub在 3000 个磁盘池上运行多长时间（但您想定期清理）。同样，zpool status对于如此大量的磁盘，诸如此类的命令的输出也会很笨拙。那么为什么要把所有的鸡蛋放在一个篮子里呢？
（关于dedup 的旁注：请注意，虽然可以在数据集级别控制 dedup，但它会在池级别找到重复项。也就是说，如果您按照建议进行分区，则可能会得到更糟的 dedup 结果。另一方面，您会需要更多内存来保存单个巨型池的重复数据删除哈希，如果池太大，可能不适合 ARC+L2ARC。因此，如果您使用重复数据删除，可用内存量可能是最大实际池大小的一个很好的指标.)