Chienomi

btrfsを構成するディスクが壊れてからRMAで交換発送するまで

western-digital

  • TOP
  • Old Archives
  • btrfsを構成するディスクが壊れてからRMAで交換発送するまで

障害の発生と確認

2015-12-31朝、いつものようにディスクを復号化し、マウントするとエラーが表示された。 ここのところ好調だったため、念の為Scrubを開始した。

# btrfs scrub start /world

そして、恐怖を味わうこととなる。

scrub started at Thu Dec 31 11:32:28 2015, running for 03:14:49
total bytes scrubbed:3.03TiB with 7192102 errors
error details: read=7192102

エラーが出るのははじめてではないが、数が異常だ。そして、これらはそのほとんどがuncorrectableと提示される。RAID1で組んでいるため、通常は修正されるし、修正されなかったのは初めてだ。

ここで仕組みを説明しよう。

通常ファイルシステムは、ひとつのブロックデバイス(ディスクパーティションであることが普通)上に作成され、独立したファイルの管理となる。 しかし、btrfsは1台以上の任意のブロックデバイス上に作成することができる。 WindowsでいえばC:やD:といった単位は、通常はディスクの数以上(ディスクにパーティションがひとつなら1、2つなら2)だが、複数のブロックデバイス上に作成できるため、2台、3台で1つのドライブにすることができる。

実はこのようなことはWidnowsでもできたりする。ダイナミックディスク機能だが、扱いにくいのでほぼ使われることはない。 複数のブロックデバイスを結合するファイルシステムというのは、クラスタファイルシステムにとって普通のことであるといえる。GSFやOCFSなど色々とある。そして、ZFSもそうだ。 だが、普通はディスクは全て同じ容量でなければならないか、違う容量であった場合は最も小さいディスクに合わせられる。btrfsはこの制限がないばかりか、3台のディスクでディスク容量合計の1/2のミラーを行うようなことができる。ただし、ここでは詳しくは述べない。

btrfsは低速だが堅牢を志向している。ブロックが壊れた場合—アクセス中に電源断にあったとか、宇宙線で飛ばされたとか—に検出できるだけでなく、そもそも壊れないようにするし、壊れた場合でも複数のディスクに同一の内容を記録するRAID1(ミラーリング)機能を用いていれば別のミラーを参照することで訂正することすら可能だ。 また、運用しながらディスクを追加/除去することも可能。

この仕組みのため、エラーは起こらないように設計されているはずなのに少なく見積もっても他のファイルシステムの数百倍は壊れるファイルシステムでありながら、実際にRAID1構成でデータが壊れてしまうことはまず発生しない。

それでありながら修復しようとしたら700万を越えるエラーが発見され、しかも修正できないというのはただごとではない。

2時間を過ぎてシステム全体がフリーズした。完全に。 btrfsの操作は結構システムをフリーズさせることが多い。busyで止まって、そのまま息絶えてしまうのだ。

700万というのは異常なので、次にファイルシステムのチェックを行う。この時点からPCは使えない。

# btrfsck --repair --check-data-csum /dev/mapper/worlddisk01

そして、大量に出力される、デバイスエラー、blk_update。果てしなく出力され続ける。 こうなると、ディスクが怪しいように感じるが、しばらく出力されるエラーを眺めてみることにした。

ほとんどは/dev/sddだが、ちょいちょい/dev/sdcがまじる。

7時間後、ファイルシステムエラーなしでfsck終了。

それで直ったとは到底思えないが再度scrub。15分後、システム停止。

そこで、smartctlを用いてディスクをチェックする。結果、sdb, sdeはエラーにならないが(現在、マスター系btrfsは4台のクラスタである。なお、sdaはシステム用のSSD)、sdc, sddは通過しない。特にsddは瞬殺だ。

つまり、ディスクが2台壊れた。少なくともsddはもはや動かなくなるのも時間の問題だ。

2レッグミラーなので、1台壊れても同じデータはもう1台にある。しかし、2台壊れるとデータは失われる。btrfsは複雑なミラーリングを行うため、必ずしも対になるディスクはないので、2台壊れた時に損失する可能性は非常に高い。

4台のクラスタで2台が同時に故障する確立は、どれだけ多めに見積もっても百万分の一に満たない。それが大晦日など「特別な日で、かつ長期の休み」と重なる確率は天文学的な値になるはずだ。

データの保全

まだマウントはできるため、とりあえずsystemdユニットを修正してro(読み取り専用)でマウントするようにして、スレーブ系にrsyncで送る。

スレーブ系はbtrfsだが、マウント時に自動でスナップショットを取るようになっている。そのため、手動で消さない限りデータの履歴を取り出すことができる。 rsyncは差分でデータを送るが、既に既存のデータが破損している可能性がある。 この場合は、rsyncで差分が送られ、スレーブ側のデータは破壊される。ただし、スナップショットによって履歴が取り出せることで、正しいデータに修正することができる。

問題は前回のミラーリング以降に追加または更新されたデータだ。それが壊れていた場合はそれは失うしかない。

rsyncはエラーを起こすことなく終了した。もしbad blockにあるデータが差分に存在したらblk_update_requestを発行せざるをえないし、もしミラーされている両方のデータのcsumが合わない場合はbtrfsはRead errorになるはずなので、エラーなく終了したということは恐らく全データが無事転送されたはずだ。

データを失うことは避けられたか？

なお、私のシステムはRAID1ミラーリングにソフトミラーリングという構成で、2段冗長構成になっている。この台数でRAID1ミラーでデータが失われる可能性は極めて低い一方で、この冗長性のためにこの膨大なディスク容量に対して3倍のコストがかかる。 スレーブ系はやめてしまおうかと考えたこともあったが、もしそれを実行していたら、私は5TBに渡る全てのデータを損失していたことになる。

ディスクの除去

まずはsddをこのままにしておくと致命傷になる可能性があるため除去を試みるが、ファシルステム6TB(全体では12TBで、RAID1のため半分)に対して使用量は5TB。 当然ながら、4台から1台を除去するためには使用率は75%以下でなくてはいけない。しかし、5/6は0.833なので明らかにできない。

# btrfs device delete /dev/mapper/world03 /world

案の定、34時間後、No space left on device.ということで失敗した。 Bad blockが多いために余計に時間がかかった感じだ。

ちなみに、方法はもうひとつあった。 そもそもディスクを除去してしまい、degradedでマウントした上で

# btrfs device delete missing /world

する方法だ。壊れたディスクが1台ならこれでもよかったのだが、sdcも壊れていたため、sdcでは壊れているがsddでは生きているデータがある可能性も考えるとかなりためらわれた。scrubできないので、これを予め解消できない。

そして、replaceという方法を別にすれば手順は

  1. sddを除去
  2. 新ディスクを取り付ける
  3. balance(sdcがえらいことになるかも)
  4. sdcを除去
  5. 新ディスクを取り付ける
  6. balance

なので、軽く10日はかかる計算となる。

また、成功した場合でもsdcとsddが死んでいるため、開いていないから気づいていないだけで壊れているデータが紛れ込んでいる可能性があり、なかなか怖い。

ディスクの発注

34時間の間に発注した。

なんといっても大晦日だったので、2日のアキバの初売りに突撃するか(体調もよくないのに辛いだろう)、ネットで発注するかだった。

結局悩んだ上で、深夜3時にツクモネットショップで発注。今回はSeagateが2,4TBがセール、TOSHIBAが3,4,6,8TBがセールだったため、単価の安い3TBは元値が高いTOSHIBAしかなく、ネットショップの通常セールでSeagateの3TBのほうが税込みだとわずかに安かった。交通費を含めると確実にやすかったためネットショップ発注。

ただし、発送が4日以降だったため、結局到着したのは5日だった。

復旧

device deleteしている最中に発案したのが、もう現在のマスター系のファイルシステムは破棄して、新しいディスクで新規のbtrfsを構築してデータを逆向きに同期することで復元するというバックアップを用いた方法だった。

スレーブ系は全てのデータを持っているはずなので、問題はないはずだ。

device deleteに失敗したことを踏まえてこれを実行。rsync -aHvで36時間を要した。

sent 82,870,445 bytes  received 4,285,991,604,707 bytes  36,456,286.60   bytes/sec

total size is 4,358,770,747,505  speedup is 1.02

仮想マシン関連のデータは破棄することとなるため、データサイズはある程度減っている。

この方法、ディスク数が増えてくると所要時間は逆転する。 今回の場合、1台あたりが3TBで、データ総量が4.3TB。 3TBのブロックを他のディスクに移すよりも4.3TBを転送するほうが早く、そのあとbalanceすることを考えれば圧倒的に早い。ただし、同時接続してdevice replaceする場合はまた話が変わってくる。

RMA

ディスクはWD Greenで保証期間内だ。ウェスタンデジタルのディスクは交換保証がついている。

RMAの手順と方法については、KLX/ITLOGに非常に詳しく書かれているので、ほぼこの通りで良い。

そして、ここに書かれている通り、名前を漢字で登録した結果文字化けてRMAを作りなおしてもらうということもやってしまった。ちなみに、私はサポートにメールフォームからメールした。

嬉しいことに交換理由にSMARTエラーという項目があり、話が早い。

ESDバッグや5cmものクッションなどハードルが高いが、比較的IT機器の購入が多く、梱包も保存している(この手のことを予測して)ため、なんとかなった。

また、発送先なのだが、東京にdrop pointが作られたため、東京港に送ればよくなった。費用的には小さく、送りやすく、それでいて配送品質も保たれるようになってハッピーだ。

RMAが結構やりやすいので、これで通ってくれたら、今後は保証期間の長さのためにWD REDを買ってもいいかもしれない。(故障しないというのは信用しない。特に運のない私の場合は)

結果

  • 障害時間は156時間
  • 手順や対応は極めて良く、迅速であった
  • データの損失は恐らくない
  • 資産的損失はRMAが通れば送料片道でしかないから大したことない
  • だが、年末年始が見事なまでに潰れた
  • ライフもかなり削った感じ