我最近将批量数据存储池(ZFS On Linux 0.6.2、Debian Wheezy)从单设备 vdev 配置迁移到双向镜像 vdev 配置。
先前的池配置是:
NAME STATE READ WRITE CKSUM
akita ONLINE 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
重新同步完成后,一切都很好(重新同步完成后,我启动了清理,只是为了让系统再次检查所有内容并确保一切正常):
pool: akita
state: ONLINE
scan: scrub repaired 0 in 6h26m with 0 errors on Sat May 17 06:16:06 2014
config:
NAME STATE READ WRITE CKSUM
akita ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
ST4000NM0033-Z1Z333ZA ONLINE 0 0 0
errors: No known data errors
然而,重启后,我收到一封电子邮件,通知我池子不太好。我查看了一下,结果如下:
pool: akita
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: scrub in progress since Sat May 17 14:20:15 2014
316G scanned out of 1,80T at 77,5M/s, 5h36m to go
0 repaired, 17,17% done
config:
NAME STATE READ WRITE CKSUM
akita DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
ST4000NM0033-Z1Z333ZA UNAVAIL 0 0 0
errors: No known data errors
清理是意料之中的事情;有一个 cron 作业设置用于在重启时启动完整的系统清理。但是,我绝对没有想到新硬盘会从镜像中掉出来。
我定义了映射到 /dev/disk/by-id/wwn-* 名称的别名,并且如果这两个磁盘都已允许 ZFS 自由使用整个磁盘,包括处理分区:
# zpool history akita | grep ST4000NM0033
2013-09-12.18:03:06 zpool create -f -o ashift=12 -o autoreplace=off -m none akita ST4000NM0033-Z1Z1A0LQ
2014-05-15.15:30:59 zpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ ST4000NM0033-Z1Z333ZA
#
这些是 /etc/zfs/vdev_id.conf 中的相关行(我现在注意到 Z1Z333ZA 使用制表符进行分隔,而 Z1Z1A0LQ 行仅使用空格,但老实说,我不明白这与这里有什么关系):
alias ST4000NM0033-Z1Z1A0LQ /dev/disk/by-id/wwn-0x5000c500645b0fec
alias ST4000NM0033-Z1Z333ZA /dev/disk/by-id/wwn-0x5000c50065e8414a
我看了看,/dev/disk/by-id/wwn-0x5000c50065e8414a*
果然在那里,但是/dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA*
却不在。
发出此命令sudo udevadm trigger
导致符号链接显示在 /dev/disk/by-vdev 中。但是,ZFS 似乎并没有意识到它们在那里(Z1Z333ZA 仍然显示为UNAVAIL
)。我想这是可以预料到的。
我尝试更换相关设备,但没有成功:
# zpool replace akita ST4000NM0033-Z1Z333ZA
invalid vdev specification
use '-f' to override the following errors:
/dev/disk/by-vdev/ST4000NM0033-Z1Z333ZA-part1 is part of active pool 'akita'
#
在启动过程中检测到两个磁盘(dmesg 日志输出显示相关驱动器):
[ 2.936065] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2.936137] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2.937446] ata4.00: ATA-9: ST4000NM0033-9ZM170, SN03, max UDMA/133
[ 2.937453] ata4.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 2.938516] ata4.00: configured for UDMA/133
[ 2.992080] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3.104533] ata6.00: ATA-9: ST4000NM0033-9ZM170, SN03, max UDMA/133
[ 3.104540] ata6.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 3.105584] ata6.00: configured for UDMA/133
[ 3.105792] scsi 5:0:0:0: Direct-Access ATA ST4000NM0033-9ZM SN03 PQ: 0 ANSI: 5
[ 3.121245] sd 3:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 TB/3.63 TiB)
[ 3.121372] sd 3:0:0:0: [sdb] Write Protect is off
[ 3.121379] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 3.121426] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 3.122070] sd 5:0:0:0: [sdc] 7814037168 512-byte logical blocks: (4.00 TB/3.63 TiB)
[ 3.122176] sd 5:0:0:0: [sdc] Write Protect is off
[ 3.122183] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[ 3.122235] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
两个驱动器都直接连接到主板;不涉及板外控制器。
一时冲动,我这么做了:
# zpool online akita ST4000NM0033-Z1Z333ZA
看起来这个方法奏效了;Z1Z333ZA 现在至少正在ONLINE
重新同步。在重新同步大约一个小时后,它扫描了 180G,重新同步了 24G,完成了 9.77%,这表明它没有进行完整的重新同步,而是只传输了数据集增量。
说实话,我不确定这个问题是否与 Linux 上的 ZFS 或 udev 有关(它有点像 udev,但为什么一个驱动器能被正常检测到,而另一个却不能),但我的问题是我如何确保下次重启时不会再次发生同样的事情?
如果有必要,我很乐意提供有关设置的更多数据;只需告诉我需要什么即可。
答案1
这是一个 udev 问题,似乎是特定于 Debian 和 Ubuntu 变体。我在 Linux 上的大部分 ZFS 工作都是在 CentOS/RHEL 上进行的。
看:
/dev/disk/by-id 下同一硬盘的 scsi 和 ata 条目
和
Linux/Ubuntu 上的 ZFS:Ubuntu 从 13.04 升级到 13.10 后,帮助导入 zpool,设备 ID 已更改
我不确定 Debian/Ubuntu 系统最确定的池设备方法是什么。对于 RHEL,我更喜欢在通用池设备上使用设备 WWN。但其他时候,设备名称/序列号也很有用。但 udev应该能够控制这一切。
# zpool status
pool: vol1
state: ONLINE
scan: scrub repaired 0 in 0h32m with 0 errors on Sun Feb 16 17:34:42 2014
config:
NAME STATE READ WRITE CKSUM
vol1 ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
wwn-0x500000e014609480 ONLINE 0 0 0
wwn-0x500000e0146097d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
wwn-0x500000e0146090c0 ONLINE 0 0 0
wwn-0x500000e01460fd60 ONLINE 0 0 0