障害の発生と確認2015-12-31朝、いつものようにディスクを復号化し、マウントするとエラーが表示された。ここのところ好調だったため、念の為Scrubを開始した。/worldそして、恐怖を味わうこととなる。read=7192102エラーが出るのははじめてではないが、数が異常だ。これらはそのほとんどがuncorrectableと提示される。RAID1で組んでいるため、通常は修正されるし、修正されなかったのは初めてだ。ここで仕組みを説明しよう。通常ファイルシステムは、ひとつのブロックデバイス(ディスクパーティションであることが普通)上に作成され、独立したファイルの管理となる。btrfsは1台以上の任意のブロックデバイス上に作成することができる。WindowsでいえばC:やD:といった単位は、通常はディスクの数以上(ディスクにパーティションがひとつなら1、2つなら2)だが、複数のブロックデバイス上に作成できるため、2台、3台で1つのドライブにすることができる。実はこのようなことはWidnowsでもできたりする。ダイナミックディスク機能だが、扱いにくいのでほぼ使われることはない。複数のブロックデバイスを結合するファイルシステムというのは、クラスタファイルシステムにとって普通のことであるといえる。GSFやOCFSなど色々とある。普通はディスクは全て同じ容量でなければならないか、違う容量であった場合は最も小さいディスクに合わせられる。btrfsはこの制限がないばかりか、3台のディスクでディスク容量合計の1/2のミラーを行うようなことができる。ここでは詳しくは述べない。btrfsは低速だが堅牢を志向している。ブロックが壊れた場合—アクセス中に電源断にあったとか、宇宙線で飛ばされたとか—に検出できるだけでなく、そもそも壊れないようにするし、壊れた場合でも複数のディスクに同一の内容を記録するRAID1(ミラーリング)機能を用いていれば別のミラーを参照することで訂正することすら可能だ。運用しながらディスクを追加/除去することも可能。この仕組みのため、エラーは起こらないように設計されているはずなのに少なく見積もっても他のファイルシステムの数百倍は壊れるファイルシステムでありながら、実際にRAID1構成でデータが壊れてしまうことはまず発生しない。それでありながら修復しようとしたら700万を越えるエラーが発見され、しかも修正できないというのはただごとではない。2時間を過ぎてシステム全体がフリーズした。btrfsの操作は結構システムをフリーズさせることが多い。busyで止まって、そのまま息絶えてしまうのだ。700万というのは異常なので、次にファイルシステムのチェックを行う。この時点からPCは使えない。/dev/mapper/worlddisk01そして、大量に出力される、デバイスエラー、blk_update。果てしなく出力され続ける。なると、ディスクが怪しいように感じるが、しばらく出力されるエラーを眺めてみることにした。ほとんどは/dev/sddだが、ちょいちょい/dev/sdcがまじる。7時間後、ファイルシステムエラーなしでfsck終了。それで直ったとは到底思えないが再度scrub。15分後、システム停止。そこで、smartctlを用いてディスクをチェックする。sdeはエラーにならないが(現在、マスター系btrfsは4台のクラスタである。