我在 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 和长 by-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。如何清除?
答案1
只需运行zpool clear solaris
然后发布结果zpool status -v
。
了解所涉及的硬件和所使用的控制器就好了。
编辑
查看blkid
输出,您有以前的 Linux 软件 RAID 的残留。您需要mdadm --zero-superblock /dev/sdb1
清除它。
答案2
在互联网、服务器故障和堆栈溢出中搜索了一天多之后,什么也没找到。我问了这个问题,答案出现在右侧的相关问题中。所以我在这个问题上找到了答案:
升级 Ubuntu 后,一个 zpool 中的所有驱动器都标记为不可用
由于某种原因,madam 在启动时运行,并启动 md0,即使 md0 不包含任何磁盘(如错误中所示),也会导致此错误。
简单来说
mdadm --stop /dev/md0
成功了,现在我的磁盘正在重新镀银。结案了。
答案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) 我有意做出这种权衡,以获得使用不需要两个人和一辆手推车移动的消费级硬件的好处……这是一个可以接受的权衡。
(编辑:更正。)