geli のデータ整合が恐くなった2008年10月05日 16時45分23秒

ディスクを間違って初期化してしまったので構築し直す必要があった。折角の機械なので、geli の比較的新しい機能を使ってみることにした。geli でデータの整合性の点検をすることが出来る。

geli init -a を行なった時点から、ディスクから読み出されるデータがチェックサムと合うか検証される。その為、少なくとも先頭領域を dd で削除しないと、newfs が出来ない。恐らく数十 MB ぐらいをゼロ書き込みするのが手っ取り早い。その後の newfs 自身が、newfs が使うブロックを初期化するので、全てのディスクをゼロ書き込みする必要は無いと思われる。UFS のバージョン 2 は遅延初期化をするので、必要の無いブロックにはすぐには書き込まない。

softupdate を有効にして、このディスクに rsync で書き込みを行なっていた。バックアップディスクが微妙に不安定で、運悪く panic を起こしてしまったようだ。

その後、この新しく整合性の点検を入れたディスクの fsck を行なった。書き込みの最中に止まったので、ファイルシステムは否が応にも不整合が起きている。しかし、今回はそれだけでなく、geli のレベルでも問題があった。チェックサムが合わなくなっていた。そして、geli dmesg に問題があるのを報告し、ゼロクリアされたデータを返している様だった。そして fsck はファイルシステムを修正しようとする。しかし、大量の意図しない結果が返ってきているようだった。そして、このファイルは存在しない、あのファイルは存在しないと言い出し、大量のファイルの削除を試み始めた。

どうも、home 以下の重要なディレクトリを更新している最中に、システムが止まり、home の i-node の書き込みが一番中途半端な所で終わってしまった様だ。softupdate は新しい home の内容を指すブロックを作る。そして、home の i-node を更新する。この書き込みが行なわれている間に、失敗したようだ。

整合性の点検が無い場合は、home の i-node は新しいブロックか古いブロックのどちらかを指している。その為、存在していたディレクトリは少なくとも、どちらの場合もそのまま残っている。今回は、この i-node 更新中のブロックのチェックサムが壊れた様だ。fsck が home を点検している時に、uyota など無いと言われた。その後、uyota 以下のファイルを参照している i-node が無いと、削除を始めた。

この一件で、整合性の点検を有効にした geli が恐くなったので、使うのを止めた。大量にファイルが消えたのは偶然かも知れないが、一回目の fsck で、ファイルが消えるような状況にでくわすと出会すと不安になる。