geli のデータ整合が恐くなった ― 2008年10月05日 16時45分23秒
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 で、ファイルが消えるような状況にでくわすと出会すと不安になる。
最近のコメント