副題に補題がつくほどこの作業が大変だったわけです。というか、これで1週間ほどが過ぎ去ったので記事が遅れた、という側面も否定できません。ということで、何が起こったのかを時系列をおいながら書きたいと思います。前回からの続きとなります。
SATAインタフェースカードの交換作業
単純に「SATA10ポート×1枚」を「SATA6ポート×2枚」にする作業です。ただし、対象のSATA3-I6-PCIEはPCI Express3.0 x2なので、それがささる場所が必要です。今回使っているM/Bがグラフィック用のPCI Expreess3.0 x16形式が2カ所あるタイプだったのでその2カ所を使うことでこの問題をパスすることができました。(もちろん、それを知っていてこの組み合わせにしています)
あとは「HDDの認識順番に合うように」SATAケーブルを接続する、という作業です。SATA3-I6-PCIEは前回のSATA3I10-PCIEとは異なり物理コネクタ位置と認識順番は一致しているようなので、よりCPUに近い側が認識順番が早いだろうという考えの元接続作業を行えば完了です。本来ならば一度サーバOSとは別環境でHDDがどの順番で認識するかチェックする必要があるのですが、そのあたりは説明書等で確認してしまえばそれほど問題はありませんでした。
SATAインタフェースカードを交換すると…先に8番目のHDDが異常に
実はこれが完全な予定外な案件でした。SATAインタフェースカードを交換すればあとはscrub処理をかけて、不良セクタが出かかっている3番目のHDDを交換して…と考えていましたが、先に8番目のHDDがSATAコマンドの送受信でエラーとなってしまってかなりまずい状態になってしまった、というところから今回の交換が大変になってしまった訳です。仕方がないので3番目の交換は後回しにして8番目の交換だけ行うことにしました。
ただし、すでにZFSのコマンドを使って8番目のHDDを切り離して…という処理をしている余裕がない状態だったため、物理的にHDDを切り離して交換用のHDDと取り替えた上で再同期処理を行う、という手順に出ました。詳しい手順はこちらの記事で。
再同期処理でエラーが発生
そして再同期中にエラーが起こってしまうわけです。おそらく前回のタイミングかそれより以前のタイミングでファイルが破損してしまったのでしょうね。こんな感じのエラーが出ます。
pool: tank state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since (日時) 12.4T scanned at 426M/s, 5.85T issued at 201M/s, 41.4T total 749G resilvered, 14.12% done, 2 days 03:29:48 to go config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz2-0 DEGRADED 0 0 0 zfs1 ONLINE 0 0 2 zfs2 ONLINE 0 0 2 zfs3 ONLINE 0 0 2 zfs4 ONLINE 0 0 2 zfs5 ONLINE 0 0 2 zfs6 ONLINE 0 0 2 zfs7 ONLINE 0 0 2 replacing-7 DEGRADED 0 0 2 1914476987721512675 OFFLINE 0 0 0 was /dev/disk/by-partlabel/zfs8/old zfs8 ONLINE 0 0 0 (resilvering) errors: Permanent errors have been detected in the following files: /tank/data/dat.zip
ちなみに日時とファイル名はちょっといじってありますが、こんな感じです。resilverの作業中にファイル破損(しかも永続)が見つかってしまった、というものです。これが起こってしまうと対象のファイルのデータは基本的に取り出すことができない、という致命的な問題です。もうこれに関しては諦めるしかありません。SATAインタフェースの問題ですのでコマンドの発行ミスがあればデータもバグが出るでしょうからそんなものだと思います。
問題はこの後です。とりあえず起こってしまったことはしょうがないので取り合えずresilver作業が一巡してZFSのRAID-Z2が復旧してからファイルの状態を確認して…見ようとできなかった、というのが今回の主題です。
なぜかRAID作業が終わらない
で、放置して再同期が終わったはずのポイントでzpoolをチェックしてみるとなんと勝手にresilver作業が2周目に突入するという事態に。は?と思いましたよ。わけがわからずとりあえずresilver作業を止めたかったのですが「止められないやめられない」(ちょっと違う?)状態に。detach処理を行っても結局裏で構築している様子で止まることなく再同期。ちなみにエラーが出たファイルをしてもエラーが解消される訳でもなくこんな状況に。
errors: Permanent errors have been detected in the following files: tank:<0x7a0>
マジでどうしよう?でした。ちなみに、途中で「ファイルが削除されてCHECKSUMエラーが検出されなければresilver作業は終わるのでは?」と考えてzpool clearもかけて見たのですが結局解消されず、なんと3周目に突入するという訳のわからない状態となってしまいました。この間にも実は3番目のHDDがRead Errorを起こしたりと非常に危険な状態になっていました。すでに不良セクタが出かかっている状態なのでさもありなん、というところでしょうか。
再同期作業を停止させて一度zpoolをエラーがない状態に戻す必要が合った様子
仕方がないので3周目の再同期を強制的に停止すべく、「一度サーバを物理的に停止させてHDDの認識を外す」処理を行いました。あまりよくない作業ですがね。ちなみにresliver処理は再起動程度では停止させることはできませんのであしからず。ちゃんと前の状態を記憶して再同期しようとする優秀な機能(微妙に皮肉)です。
さすがに物理的にHDDが切り離されれば再同期対象のHDDがありませんので作業は一気に進み、とりあえずRAID-2Z全体から見ればDEGRADED状態ながらresilverは終わりましたので、Permanent errosを取り除く必要があります。が、どうも以下の手順がいるようです。
- Permanent errorsとなっているファイルを削除(今回はすでに削除済み)
- Permanent errorsをリセットするために一度scrub処理(今回はHDDを切り離した後のresilver処理が代わりとなった)
- 状態をクリアするためにzpool clearを発行
本来は1~3の処理が必要のようですが、再同期処理などが代わりとなってPermanent errorsを解消することに成功したのが大きかったです。scrub処理は3番目のHDDがかなり危険な状態になっていますので行いたくなかったのですが、しなくても何とかなったのでよかったです。ちなみに、ここまでに(故障に気がついてから)2週間ほどかかっています。
Permanent errorsがなくなればあとは再同期処理をもう一度発行するだけ
やっと終わりましたので再度HDDをつなぎ直してrepairを行います。実はこの作業もかなり祈りが必要な状態でした。3番目は壊れかかっていますのでまた読み込みエラーなどが出たら再同期に失敗する可能性もありますし、また破損ファイルが出てくると同じような作業を行ってエラーを解消しないと再同期できないことはわかっている状態なので、致命的なエラーだけは出てほしくない場面でした。で、3日間ほど放置して結果としては
pool: tank state: ONLINE scan: resilvered 5.18T in 2 days 11:17:26 with 0 errors on (作業開始日時) config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 zfs1 ONLINE 0 0 0 zfs2 ONLINE 0 0 0 zfs3 ONLINE 0 0 0 zfs4 ONLINE 0 0 0 zfs5 ONLINE 0 0 0 zfs6 ONLINE 0 0 0 zfs7 ONLINE 0 0 0 zfs8 ONLINE 0 0 0 errors: No known data errors
と、なんとか一度再同期作業が成功して一息つけた、というわけです。
最後に3番目のHDDを交換して…
ここで終えられたら楽なのですが、Read Errorが微妙な件数報告されていたり、SMARTの報告がかなり危なかったりしますのでやはり交換対象、というわけで次に続きます。次でこの話は最後になると思います。