為什麼重新啟動會導致我的 ZFS 鏡像的一側變為不可用?
我最近剛剛將大容量數據儲存池(Linux 0.6.2 上的 ZFS,Debian Wheezy)從單設備 vdev 配置遷移到雙向鏡像 vdev 配置。
以前的池配置是:
NAME STATE READ WRITE CKSUM akita ONLINE 0 0 0 ST4000NM0033-Z1Z1A0LQ ONLINE 0 0 0
resilver 完成後一切都很好(我在 resilver 完成後啟動了一次清理,只是為了讓系統再次檢查所有內容並確保一切正常):
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,但為什麼會檢測到一個驅動器而另一個驅動器卻沒有),但我的問題是我該怎麼做確定下次重啟時不會再發生同樣的事情?
如有必要,我很樂意提供有關設置的更多數據;只是讓我知道需要什麼。
這是一個 udev 問題,似乎特定於 Debian 和 Ubuntu 變體。我在 Linux 上的大部分 ZFS 工作都是使用 CentOS/RHEL。
請參閱: 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