ZFS 池报告丢失设备，但设备并未丢失

Question 1

只需运行zpool clear solaris然后发布结果zpool status -v。

了解所涉及的硬件和所使用的控制器就好了。

编辑

查看blkid输出，您有以前的 Linux 软件 RAID 的残留。您需要mdadm --zero-superblock /dev/sdb1清除它。

Answer

只需运行zpool clear solaris然后发布结果zpool status -v。

了解所涉及的硬件和所使用的控制器就好了。

编辑

查看blkid输出，您有以前的 Linux 软件 RAID 的残留。您需要mdadm --zero-superblock /dev/sdb1清除它。

Question 2

在互联网、服务器故障和堆栈溢出中搜索了一天多之后，什么也没找到。我问了这个问题，答案出现在右侧的相关问题中。所以我在这个问题上找到了答案：

升级 Ubuntu 后，一个 zpool 中的所有驱动器都标记为不可用

由于某种原因，madam 在启动时运行，并启动 md0，即使 md0 不包含任何磁盘（如错误中所示），也会导致此错误。

简单来说

mdadm --stop /dev/md0

成功了，现在我的磁盘正在重新镀银。结案了。

Answer

在互联网、服务器故障和堆栈溢出中搜索了一天多之后，什么也没找到。我问了这个问题，答案出现在右侧的相关问题中。所以我在这个问题上找到了答案：

升级 Ubuntu 后，一个 zpool 中的所有驱动器都标记为不可用

由于某种原因，madam 在启动时运行，并启动 md0，即使 md0 不包含任何磁盘（如错误中所示），也会导致此错误。

简单来说

mdadm --stop /dev/md0

成功了，现在我的磁盘正在重新镀银。结案了。

Question 3

我知道这是一个五年前的问题，你当前的问题已经解决了。但这是网络搜索中关于丢失的 ZFS 设备的少数具体搜索结果之一（至少是我使用的关键字），它可能有助于其他人了解这一点：

这个设备“丢失”的特定问题是 Linux 上 ZFS 的一个已知问题。（特别是在 Linux 上。）我认为，这个问题有两个方面，虽然 ZOL 团队可以自己修复它（可能需要大量工作），但事实并非如此完全ZOL 问题：

虽然没有操作系统具有完全稳定的设备引用方式，但对于这种特定用例，Linux 比 Illumos、BSD 或 Solaris 等稍差一些。当然，我们有设备 ID、GUID，甚至更好的——较新的“WWN”标准。但问题是，一些存储控制器——特别是一些 USB（v3 和 4）控制器、eSATA 和其他控制器，以及许多类型的消费级外部机箱——要么无法始终看到这些，要么更糟的是，无法将它们传递给操作系统。仅仅将电缆插入外部机箱的“错误”端口就可能在 ZFS 中触发此问题，并且无法避免。
由于某种原因，ZOL 无法识别磁盘确实存在且对操作系统可见，只是不在 ZFS 之前知道的任何先前位置（例如 /dev、/dev/disk/by-id、by-path、by-guid 等）或更确切地说，不在特定的先前位置。即使您在移动任何内容之前执行了正确的 zpool 导出。这对于 ZOL 或 ZFS 尤其令人沮丧。（我甚至在 Solaris 上也记得这个问题，但那是 ZFS 的一个相当老的版本，如果 ZIL 丢失，整个池就会丢失……我曾经因此丢失了所有内容 [但有备份]。）

明显的解决方法是不要使用带有 ZFS 的消费级硬件，尤其使用某些消费者级协议（如 USB、Firewire、eSATA 等）的消费者级外部机箱。（外部 SAS 应该没问题。）

具体来说，消费级外部机箱给我带来了无尽的麻烦。虽然我偶尔在使用稍微更“企业”级的 LSI SAS 控制器和带有 5x4 托架的机架式机箱时会遇到这种特定问题，但转向带有三个外部托架的更便携的解决方案几乎带来了地狱般的麻烦。幸好我的阵列是三向镜像的条纹，因为有一次它真的失去了对8 个驱动器（总共 12 个），唯一的解决方案是重新同步它们。（大部分读取速度为 GB/s，因此至少不需要几天或几周的时间。）

所以我不知道长期的解决方案是什么。如果志愿者们觉得覆盖消费级硬件的所有边缘情况（特别是 Linux）超出了范围，我不会责怪他们编写了这么多代码。

但我认为，如果 ZFS 对每个磁盘上 ZFS 自身管理的元数据进行更详尽的搜索，将解决许多相关问题。（例如，Btrfs 完全不存在这个问题。我可以完全随机地随意移动东西，它从来没有抱怨过。当然，与 ZFS 相比，Btrfs 还有其他缺点（优点和缺点的列表是无穷无尽的），而且它也是原生 Linux——但这至少表明问题能，理论上可以解决，至少在Linux上，具体由软件本身解决。

我已经想出了一个解决这个问题的办法，现在已经实现了全部我的 ZFS 阵列，即使在工作中，即使在企业硬件上：

关闭外部机柜，这样 ZFS 就不会自动导入池。（令人沮丧的是，似乎仍然没有办法告诉 ZFS 不要这样做。重命名缓存文件或将其设置为“无”不起作用。即使没有寻址问题，我也几乎从不希望池自动挂载，而是希望自动脚本来执行此操作。）
一旦系统启动并稳定下来，就打开外部机箱。
运行一个脚本，连续多次导出和导入池（有时令人沮丧的是，它需要这样做才能看到即使是合法的微小变化）。这里最重要的是以只读模式导入以避免自动重新同步启动。
然后，脚本向用户显示zpool status只读池的输出，并提示用户是否可以继续以完全读写模式导入。

这样做无数次拯救了我（或我的数据）。通常这意味着我必须移动驱动器和/或通常只是电缆，直到寻址恢复到原来的位置。它还为我提供了使用 -d 开关尝试不同寻址方法的机会。这些方法和更换电缆/位置的组合已经解决了几次问题。

在我的特定情况下，使用-d /dev/disk/by-path通常是最佳选择。因为我以前最喜欢的，-d /dev/disk/by-id实际上与我当前的设置相当不可靠。通常整个驱动器托架完全从/dev/disk/by-id目录中丢失。（在这种情况下，甚至很难责怪 Linux。这只是一个不稳定的设置，进一步加剧了前面提到的现有缺点。）

当然，这意味着不能指望服务器在没有人工干预的情况下自动启动。但考虑到 1) 它依靠大容量电池全天运行，2) 我有意做出这种权衡，以获得使用不需要两个人和一辆手推车移动的消费级硬件的好处……这是一个可以接受的权衡。

（编辑：更正。）

Answer