最近、バルク データ ストレージ プール (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 ジョブが設定されています。ただし、新しい 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再シルバー化中です。再シルバー化開始から 1 時間ほどで、180G をスキャンし、24G を再シルバー化して 9.77% 完了しました。これは、完全な再シルバー化ではなく、データセットの差分転送のみを行っていることを示しています。
正直、この問題がLinux上のZFSに関係しているのか、それともudevに関係しているのかわかりません（udevに少し似ている気がしますが、ではなぜ1つのドライブは正常に検出されるのに、もう1つは検出されないのでしょうか）。私の質問は次回の再起動時に同じことが再び起こらないようにするにはどうすればよいでしょうか?
必要であれば、セットアップに関する詳細なデータを喜んで提供しますので、必要な情報をお知らせください。
答え1
これはudevの問題のようですDebianおよびUbuntuの亜種に特有私の Linux 上の ZFS 作業のほとんどは CentOS/RHEL で行われています。
ZFS ディスカッション リストの同様のスレッドでもこれについて言及されています。
見る：
/dev/disk/by-id の下にある同じハードドライブの scsi および ata エントリ
そして
Linux/Ubuntu 上の ZFS: Ubuntu を 13.04 から 13.10 にアップグレードした後、デバイス ID が変更されたため、zpool をインポートする方法についてヘルプ
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