很长一段时间以来，我一直听说大型（>5TB？）RAID-5 阵列是一个多么糟糕的想法，因为另一个驱动器发生故障的风险很高。
RAID-Z1 是否已成功解决任何大小的阵列的这个问题（如果您确实需要一个数字，请考虑 4x2TB 或 5x2TB）？也许有一种更安全的方法来重新复制所有驱动器上不那么密集的数据？
答案1
即使考虑到这里的其他答案之一所阐述的内容，即 ZFS 仅适用于实际使用的块而不是空白空间，是的，制造大型 RAIDZ1 vdev 仍然很危险。大多数池最终至少利用了 30-50%，许多池直接达到建议的最大值 80%（有些池超过了这个数字，出于性能原因，我强烈建议您不要这样做），因此 ZFS 仅处理已使用的块并不是一个巨大的优势。此外，其他一些答案听起来像是读取错误导致了问题。事实并非如此。块内的一点腐烂并不是让您陷入困境的原因，通常是另一个磁盘完全变坏，而第一个磁盘变坏的重新镀银仍在进行中，这会让您丧命。在大型 raidz1 中的 3 TB 磁盘上，甚至可能需要几天时间周重新同步到新磁盘，因此发生这种情况的可能性并不小。
我个人建议客户永远不要对大于 750 GB 的磁盘使用 RAIDZ1（相当于 RAID5），以避免很多潜在的不愉快。我可以接受他们因为其他原因（系统在其他地方有备份，数据不那么重要等）违反这条规则，但通常我会尽力推动使用 RAIDZ2 作为大磁盘的最低选择。
此外，出于多种原因，我通常建议不要在 raidz2 条带中使用超过 8-12 个磁盘，也不要在一个 raidz3 条带中使用超过 11-15 个磁盘。对于 3 TB 磁盘，您应该处于这些范围的低端，对于 1 TB 磁盘，处于这些范围的高端可能没问题。这将帮助您避免在重新同步过程中有更多磁盘发生故障，这只是其中一个原因，但却是一个重要的原因。
如果你正在寻找一些合理的经验法则（编辑 04/10/15 - 我写这些规则时只考虑了旋转磁盘 - 因为它们也是合乎逻辑的 [为什么在 raidz1 中要使用少于 3 个磁盘] 它们即使对于 SSD 池也是有意义的，但当我写下这些规则时，我脑海中并没有全 SSD 池的概念）：
- 在 > 750 GB 的磁盘上根本不要使用 raidz1。
- 不要在 raidz1 上使用少于 3 个或多于 7 个磁盘。
- 如果考虑使用 3 磁盘 raidz1 vdevs，请认真考虑使用 3 路镜像 vdevs。
- 不要在 raidz2 上使用少于 6 个或多于 12 个磁盘。
- 不要在 raidz3 上使用少于 7 个或多于 15 个磁盘。
- 一定要记住，与传统 RAID 阵列不同，在传统 RAID 阵列中磁盘数量会增加 IOPS，而在 ZFS 中则是 VDEVS 数量会增加，因此使用较短的条带 vdev 可以提高池 IOPS 潜力。
答案2
RAID-Z 是否与 R5 一样糟糕？不。它是否与 R1 或 R10 一样好？通常不是。
RAID-Z 知道驱动器上的空白点，而 R5 不知道。因此 RAID-Z 只需读取有数据的区域即可恢复丢失的磁盘。此外，数据不一定分布在所有磁盘上。一个非常小的文件可能仅驻留在单个磁盘上，奇偶校验位于另一个磁盘上。因此，RAID-5 必须读取与阵列上使用的空间完全相同的数据（如果 5TB 阵列上使用 1mb，则重建只需读取 1mb）。
反过来说，如果大型阵列的大部分都已满，那么大部分数据将需要从所有磁盘读取。相比之下，R1 或 R10 只需要从一个磁盘（每个故障磁盘；如果多个磁盘发生故障，则仅在阵列仍可恢复的情况下）读取数据。
您担心的是，每次扇区读取操作都有可能发现某个扇区写入不正确或无法再读取。对于当今的典型驱动器，该概率约为 1x10^-16（并非所有驱动器都相同，因此请查阅驱动器的规格以了解其额定值）。这种情况极少发生，但大约每 1PB 发生一次；对于 10TB 阵列，有 1% 的概率您的阵列已损坏，而您直到尝试恢复时才知道。
ZFS 也有助于减少这种可能性，因为大多数不可读的扇区都是显而易见的前您开始尝试重建阵列。如果您定期清理 ZFS 阵列，清理操作将拾取这些错误并解决它们（或提醒您，以便您可以更换磁盘，如果您愿意的话）。他们建议您每月清理企业级磁盘一到四次；消费级驱动器每周至少清理一次或更多。