Root on ZFSの突然死に終止符

暫く前にも突然死してしまった。その時はディスクエラーもあって二重障害だった。

今回からは単一障害で突然ブートしなくなった。俗に言う突然死。

USBでブートすれば、importも出来るし、マウントもでき、ZFSは健全な状態です。

結構あちらこちらで起きてるようです。

危険と言われ始めたRoot on ZFSはどうして危険なんだろう？

うちの環境では、HP Microserver G8で いわゆる　Legacy BIOSのマシンだ。それに4TのHDDを4本乗せ更に Root On ZFSの構成。パーテションは4Tに対応していると言われるGPTを使っている。

一般的に危険なのは、ブートローダーだ。元々壊れやすいので、ストライピングのディスクには置かない方が良いと言われている。故障率が倍になるからだ。

bootを移動してtarで書き戻したり、boocodeを再書き込みしたりして、ブート出来るようになった場合は運が良かったか、ローダーとコードが壊れただけだったかも知れない。

今回のように何をしても起動しない場合や、写真の後新しいブートコードを書き込むと、写真のメッセージは、Un Supportedに変わったりする。

そのような場合はもう救えないだろう。ただZFSは強いので、import 出来、マウントも出来るからデータは救いだせる。

ただ今回実行してない唯一の心残りは、

gpart recover ada0 。これはやってない。とても気になっている。

今回のケースで、怪しいのはBIOSが正確に4Tサポート出来ないのではと思っている。

booot.loader がディスクの最後に書かれたGPTの管理テーブルの位置を知る方法は
BIOSの場合は、INT13しかない。
一方 UEFIの場合は、EFI_BLOCK_IO API使っているため対応できているが、
BootはDISKの最初から２T以内に置くべき。

2Tを超えた時にBIOSが間違った値をレポートして、管理テーブルを見失うのではないかと考えている。

今回は1Gのbootを置くスライスを切ってmirrorにした。ここのbootをzrootにある/boot からシンボリックリンクを張った。

この領域はディスクの先頭から2T以内に有れば良いだろう。最初は、gptzfsbootも疑ったが、大丈夫と信じて、敢えて gptzfsboot でブートしている。