为什么重新引导会导致ZFS镜像的一侧失效?


13

我最近才将大容量数据存储池(在Linux 0.6.2上为ZFS,在Debian Wheezy上为ZFS)从单设备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作业设置,可在重新启动时启动完整的系统清理。但是,我绝对不希望新的HDD脱颖而出。

我定义了映射到/ 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,完成了9.77%的重新同步24G,这表明它没有进行完全重新同步,而只是传输数据集增量。

老实说,我不确定这个问题是否与Linux上的ZFS或udev有关(闻起来有点像udev,但是为什么一个驱动器可以被正常检测到而另一个检测不到),但是我的问题是我该怎么做确定下次重启时不会再次发生相同的事情?

如有必要,我很乐意提供更多有关设置的数据;请让我知道需要什么。

Answers:


10

这是一个udev问题,似乎特定于Debian和Ubuntu变体。我在Linux上使用的大多数ZFS是与CentOS / RHEL一起使用的。

ZFS讨论列表上的类似主题提到了这一点。

请参阅:Linux / Ubuntu上的
/ dev / disk / by-id
ZFS 下同一硬盘驱动器的scsi和ata条目
:在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

1
迁移到裸wwn-*名后,该池看起来很稳定。
2014年

1
@MichaelKjörling您能详细说明如何迁移到wwn- *名称吗?
codecowboy 2014年

1
@codecowboy一点都不花哨。zpool detach akita ST4000NM0033-Z1Z333ZA然后zpool attach -o ashift=12 -f akita ST4000NM0033-Z1Z1A0LQ wwn-0x5000c50065e8414azpool detach akita ST4000NM0033-Z1Z1A0LQ然后zpool attach akita wwn-0x5000c50065e8414a wwn-0x5000c500645b0fec,在每个步骤之间核实该池是稳定的。我强烈建议先彻底擦洗。您可能也可以避免使用zpool replace,但是由于别名指向wwn名称,并且我具有冗余和备份,因此感觉更安全。花了几天时间,但我并不着急。
2014年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.