年の瀬、公園で糞寒い中でも元気な子供達を遊ばせていると、家で掃除をしてくれていた妻からビデオ通話が入った。曰く、サーバのケーブルが抜けちゃった!

映像を見ると、抜けたのは外付けHD箱(まだこいつが動いている!)のeSATAケーブルのようだ。これ、抜けやすいんだよね…。しかたない。気にしないで、と返事して外遊びを続けた。
しばらくして帰宅して、ケーブルを再接続してからサーバの様子を見ると、メインのpoolは外付け箱のディスク群に頼らず本体だけで動くのでおいておくとして、メディアファイル置き場にしていたpoolがUNAVAIL状態に落ちていた。ディスクは繋がっているのにおかしいな。と、dmesgを見るとこんなもので埋め尽くされていた。

Dec 30 14:22:56 daemon kernel: (aprobe0:siisch1:0:15:0): SOFT_RESET. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
Dec 30 14:22:56 daemon kernel: (noperiph:siisch1:0:(aprobe1:siisch1:0:0:0): CAM status: Unconditionally Re-queue Request
Dec 30 14:22:56 daemon kernel: (aprobe0:siisch1:0:15:0): CAM status: Unconditionally Re-queue Request
Dec 30 14:22:56 daemon kernel: -1:(aprobe0:ffffffff): siisch1:0:rescan already queued
Dec 30 14:22:56 daemon kernel: 15:(noperiph:0): siisch1:0:Error 5, Retry was blocked
Dec 30 14:22:56 daemon kernel: -1:ffffffff): (aprobe1:rescan already queued
Dec 30 14:22:56 daemon kernel: siisch1:0:0:0): Error 5, Retry was blocked
Dec 30 14:22:56 daemon kernel: (aprobe1:siisch1:0:0:0): SOFT_RESET. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
Dec 30 14:22:56 daemon kernel: (aprobe0:siisch1:0:15:0): SOFT_RESET. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
Dec 30 14:22:56 daemon kernel: (noperiph:(aprobe1:siisch1:0:0:0): CAM status: Unconditionally Re-queue Request
Dec 30 14:22:56 daemon kernel: (aprobe0:siisch1:0:15:0): CAM status: Unconditionally Re-queue Request
Dec 30 14:22:56 daemon kernel: siisch1:0:(aprobe0:-1:siisch1:0:ffffffff): 15:rescan already queued
Dec 30 14:22:56 daemon kernel: 0): (noperiph:Error 5, Retry was blocked
Dec 30 14:22:56 daemon kernel: siisch1:0:-1:(aprobe1:ffffffff): siisch1:0:rescan already queued
Dec 30 14:22:56 daemon kernel: 0:0): Error 5, Retry was blocked

うわー。軽く調べると、これはケーブル不良・接触不良の疑いがある。慌ててケーブルを抜くと埃だらけ…。やばい。埃を除去して再接続すると、今度はこう来た。

Dec 30 14:40:30 daemon kernel: GEOM: ada6: corrupt or invalid GPT detected.
Dec 30 14:40:30 daemon kernel: GEOM: ada6: GPT rejected -- may not be recoverable.

ありゃりゃ。GPTが壊れた?でも、rawデバイスでpoolに入れているから、GPTがどうの出てくるのはおかしい。ということで、このpoolを構成している2台のディスクの頭の方を見てみる。

# dd if=/dev/ada6 count=4 | hd
...
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
...
4+0 records in
4+0 records out
2048 bytes transferred in 0.000387 secs (5294849 bytes/sec)
# dd if=/dev/ada7 count=4 | hd
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
4+0 records in
4+0 records out
2048 bytes transferred in 0.000433 secs (4725187 bytes/sec)
00000800

なるほど、片方にEFIディスクラベルが残っており、GEOMがそれを拾ってしまったようだ。なぜ今になって問題となったのかはわからないが、変な信号でどこかが壊れたか、それによって回復処理が走ったとか?
さて、ZFS On-Disk Specification(悲しいかな、オフィシャルな置き場所は失われたのでググって探そう)のSection 1.3によれば、ZFSボリュームの頭に置かれるvdev labelの頭の8KBはブランク、つまりZFSでは関知しないようなので、クリアしてしまおう。

# dd if=/dev/zero of=/dev/ada6 count=4
4+0 records in
4+0 records out
2048 bytes transferred in 0.000024 secs (87145228 bytes/sec)

しばらくすると、ボリュームがZFSで認識されるようになったので、zpool importで無事poolが復活した。ああ、よかった。今年もデータロスなく年を越せそうです。

Tags : ,
Categories : Tech