我在 linux 上运行最新的 Debian 7.7 x86 和 ZFS
把我的电脑搬到另一个房间后。如果我做一个 zpool status 我得到这个状态：
pool: solaris
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
scan: none requested
config:
NAME STATE READ WRITE CKSUM
solaris DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
11552884637030026506 UNAVAIL 0 0 0 was /dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN1221F308BR3D-part1
ata-Hitachi_HDS723020BLA642_MN1221F308D55D ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30N4JED ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30N4B2D ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30JBJ8D ONLINE 0 0 0
它说不可用的磁盘是 /dev/sdb1 经过一番调查，我发现 ata-Hitachi_HDS723020BLA642_MN1221F308BR3D-part1 只是对 /dev/sdb1 微笑，它确实存在：
lrwxrwxrwx 1 root root 10 Jan 3 14:49 /dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN1221F308BR3D-part1 -> ../../sdb1
如果我检查智能状态，例如：
# smartctl -H /dev/sdb
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
磁盘在那里。我可以在它上面做 fdisk ，以及其他一切。
如果我尝试将其分离，例如：
zpool detach solaris 11552884637030026506
cannot detach 11552884637030026506: only applicable to mirror and replacing vdevs
我还尝试了 /dev/sdb /dev/sdb1 和长的 ID 名称。一直都是同样的错误。
我也无法替换它，或者其他任何东西。我什至尝试关闭并再次打开计算机，但无济于事。
除非我真的自己更换硬盘，否则我看不到任何解决此问题的方法。
想法？
[更新] 犹豫
# blkid
/dev/mapper/q-swap_1: UUID="9e611158-5cbe-45d7-9abb-11f3ea6c7c15" TYPE="swap"
/dev/sda5: UUID="OeR8Fg-sj0s-H8Yb-32oy-8nKP-c7Ga-u3lOAf" TYPE="LVM2_member"
/dev/sdb1: UUID="a515e58f-1e03-46c7-767a-e8328ac945a1" UUID_SUB="7ceeedea-aaee-77f4-d66d-4be020930684" LABEL="q.heima.net:0" TYPE="linux_raid_member"
/dev/sdf1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="9314525646988684217" TYPE="zfs_member"
/dev/sda1: UUID="6dfd5546-00ca-43e1-bdb7-b8deff84c108" TYPE="ext2"
/dev/sdd1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="1776290389972032936" TYPE="zfs_member"
/dev/sdc1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="2569788348225190974" TYPE="zfs_member"
/dev/sde1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="10515322564962014006" TYPE="zfs_member"
/dev/mapper/q-root: UUID="07ebd258-840d-4bc2-9540-657074874067" TYPE="ext4"
禁用 mdadm 并重新启动后，此问题又回来了不确定为什么 sdb 被标记为 linux_raid_member。如何清除？
只需运行
zpool clear solaris然后发布结果zpool status -v。很高兴知道所涉及的硬件以及您正在使用的控制器。
编辑
查看您的
blkid输出，您有以前的 Linux 软件 RAID 的残余物。你需要mdadm --zero-superblock /dev/sdb1清除它。在搜索了一天多的互联网和服务器故障和堆栈溢出后，没有找到任何东西。我问了这个问题，答案出现在右侧的相关问题中。所以我在这个问题上找到了答案：
升级的 Ubuntu，一个 zpool 中的所有驱动器都标记为不可用
由于某种原因，madam 在 start 中运行，并启动 md0，即使 md0 不包含任何磁盘（如错误所示），它确实会导致此错误。
所以一个简单的
成功了，现在我的磁盘正在重新同步。结案。
我知道这是一个五年前的问题，你的直接问题已经解决了。但这是在网络搜索中出现的关于缺少 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 上也记得这个问题，但如果 ZIL 丢失，我认为这是一个明显较旧的 ZFS 版本，它会丢失整个池……我曾经丢失过所有东西 [但有备份]。）
显而易见的解决方法是不使用带有 ZFS 的消费级硬件，尤其是使用一些消费级协议（如 USB、Firewire、eSATA 等）的消费级外部机箱（外部 SAS 应该没问题。）
特别是——消费级的外部外壳——让我头疼不已。虽然我偶尔会在稍微多一点的“企业”级 LSI SAS 控制器和带有 5x4 托架的机架式机箱中遇到这个特定问题，但转向具有三个外部托架的更便携的解决方案，几乎释放了地狱。值得庆幸的是，我的阵列是三向镜像条带，因为在某一时刻它实际上丢失了8 个驱动器（总共 12 个驱动器），唯一的解决方案是重新同步它们。（主要以 GBs/s 的速度读取，因此至少不需要几天或几周的时间。）
所以我不知道长期的解决方案是什么。如果志愿者们觉得覆盖消费级硬件的所有边缘案例，特别是 Linux，超出了范围，我不会责怪他们。
但我认为，如果 ZFS 对 ZFS 在每个磁盘上自行管理的元数据进行更详尽的搜索，将会解决许多相关问题。（例如，Btrfs 根本不会遇到这个问题。我可以完全随意地随意移动东西，而且它从来没有抱怨过。当然，与 ZFS 相比，Btrfs 有其他缺点（优点和列表）缺点是无穷无尽的），它也是原生的 Linux——但它至少表明这个问题在理论上是可以解决的，至少在 Linux 上是可以解决的，特别是通过软件本身。
我拼凑了一个解决这个问题的方法，现在我已经在我所有的 ZFS 阵列上实现了，甚至在工作中，甚至在企业硬件上：
关闭外部机箱，以便 ZFS 不会自动导入池。（令人沮丧的是，似乎仍然没有办法告诉 ZFS 不要这样做。重命名缓存文件或将其设置为“无”是行不通的。即使没有寻址问题，我几乎从不希望池自动- mount 但宁愿使用自动脚本来执行此操作。）
一旦系统启动并稳定下来，然后打开外部机箱。
运行一个连续几次导出和导入池的脚本（令人沮丧的是，有时需要它才能看到合法的微小更改）。这里最重要的是，以只读模式导入以避免自动重新同步启动。
该脚本然后向用户显示
zpool status只读池的输出，并提示用户是否可以继续并以完全读写模式导入。这样做已经无数次地拯救了我（或我的数据）。通常这意味着我必须移动驱动器和/或通常只是移动电缆，直到寻址回到原来的位置。它还为我提供了使用 -d 开关尝试不同寻址方法的机会。一些组合，以及改变电缆/位置，已经解决了几次问题。
在我的特殊情况下，安装
-d /dev/disk/by-path通常是最佳选择。因为我以前的最爱，-d /dev/disk/by-id在我目前的设置下实际上是相当不可靠的。通常整个驱动器托架完全从/dev/disk/by-id目录中丢失。（在这种情况下，即使是 Linux 也很难责怪。这只是一个不稳定的设置，进一步加剧了前面提到的现有缺点。）当然，这意味着不能依靠服务器在没有人工干预的情况下自动启动。但是考虑到 1）它在大容量备用电池上全时运行，2）我故意做出了这种权衡，以便能够使用不需要两个人和一个小车移动的消费级硬件。 . 这是一个不错的权衡。
（编辑：更正。）