我已经使用存储空间很多年了，我想我已经了解它的工作原理。最近，我拿到了一个退役的 24 托架 SAN，并决定对其进行一些修改，以便与我的（单节点）硬件一起使用。
我现在发现了一些我无法解释的存储池的奇怪行为——因此我将从布局开始深入研究，因为也许我已经犯了一个思维错误那里这导致了我看到的问题。
因此，首先要做的事情是：
- 我有 2 个旧的 Adaptec 71605。（4x 6GB SAS 卡）
- 我的服务器纯粹由 SSD 运行，这几乎可以耗尽一个 HBA 端口。
- 因此，为了获得最大的性能，我决定创建4 个存储池，每个有 6 个 SSD，而每个 SSD 连接到另一个 HBA 端口。因此，如果一个池很忙而其他池处于休眠状态，则 6 个磁盘可以各自独占一个 HBA 端口以获得最大速度。
- 因为我需要冗余，所以 ofc 就归结为 3 列、2 个副本的布局，速度应该在 1500 MB/s 左右（每个 SSD 大约 500）
这一切似乎运行良好，经过测试，我获得了预期的性能和磁盘繁忙。
首要问题
当我为 HBA 打印一些风扇支架时，我没有将其中一个正确地放回其插槽中。正如预期12 个磁盘丢失。正如预期的那样，现在每个存储池丢失了 3 个磁盘。
然而，完全出乎意料的是：每个池都离线，并显示“故障”。无法将它们重新联机。
我最初的假设是，如果 3x2 池的 3 个磁盘发生故障，该池在降级状态下是否仍可用？
因此，我的想法是，存储空间 - 即使数据在理论上是健康的 - 也不会认为它是健康/降级的，因为不再存在任何类型的磁盘仲裁。 （那么，如果池会产生多个封闭，是否应该避免裂脑？）
第二期
上周，我遇到了一次真正的磁盘故障，这次池仍然在线，但性能下降了。太棒了，这是意料之中的事。（到目前为止）。
现在，通常发生故障的磁盘将位于失去通讯状态，直到您添加替换，将磁盘设置为已退役，复制数据并最终将其删除。（过去几年中多次这样做）
因此，令我惊讶的是，磁盘变成了已退休过了一段时间，它自己就恢复了。不管怎样，我没有再关注这个问题，而是添加了另一个磁盘，调用了虚拟磁盘的重建并删除了已报废的磁盘。
我现在看到的问题是新磁盘仍为没有使用. 所有其他磁盘的使用率大致相同 - 但虚拟磁盘报告处于健康状态，而仅使用 5 个磁盘。
这怎么可能呢？
我知道，如果池中存在未使用的磁盘，您可以修复虚拟磁盘（或存储空间会自动执行此操作） - 但池只有 6 个磁盘，其中 1 个发生故障 - 它如何“修复” 5 个磁盘上的 3 列 2 副本磁盘？
我出去了 6 天，所以这段时间我没有手动修理游泳池。
存储空间决定恢复“健康”并违反列约束是否是一种隐藏的功能 - 或者我从根本上误解了 3 列、2 个磁盘的含义？
答案1
找到了第 2 个问题的答案。即使乍一看很奇怪 - 但它绝对有道理：
- 当您从 3 列、2 个副本池开始时，它需要 6 个磁盘才能保持健康。3 个磁盘用于写入，每个副本需要 3 个磁盘。
- 当磁盘发生故障时，池将变为不健康。现在可以恢复弹性通过恢复其他磁盘上丢失的块。
- 游泳池现在可以读再次从 3 列开始，并有每个块的副本 - 因此，从读取访问从观点来看，池现在又恢复了健康。它只是无法同时写入 3*2 个磁盘。
- 当添加新磁盘时 - 池立即健康再次，即使现在还没有使用新磁盘，因为：
- 游泳池现在可以写再次改为 3 列 / 2 份。
想想这个由 1 个数据块组成的简单数据集：
附言：Optimize-StoragePool如果需要，您可以使用它来恢复正确的列对齐。
pps：我出于好奇测试了一下：当然，只有当池子有足够的未分配剩余磁盘的剩余容量。如果分配了 100%，则不会/无法恢复这样的健康状态。