最近、バルクデータストレージプール(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
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ジョブセットアップがあります。しかし、私は間違いなく新しい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つのドライブが他のドライブではなく正常に検出されるのですか)次回の再起動時に同じことが再発しないようにするにはどうすればよいですか?
必要に応じて、セットアップに関する追加のデータを提供させていただきます。必要なものを教えてください。
これは DebianおよびUbuntuバリアントに固有 のように見えるudevの問題です。 Linuxでの私のZFS作業のほとんどはCentOS/RHELを使用しています。
ZFSディスカッションリストの同様のスレッドがこれについて言及しています。
見る:
/ 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