昨日ちょっと気になったので、「ZFS Root でブートセクタがお亡くなりになった場合に復旧可能か」というのを検証してみました。

まずはテスト環境でブートセクタをふっ飛ばします。/dev/ada0p1 が freebsd-boot です。

# dd if=/dev/zero of=/dev/ada0p1
1025+0 records in
1024+0 records out
524288 bytes transferred in 0.792781 secs (661328 bytes/sec)

この状態で再起動してみます。

はい、起動しません。ここから復旧を開始します。

まずは FreeBSDインストールディスクをCDに入れます。

次に、復旧用HDDとして新たに小容量のハードディスクを追加します。通常はSATAなのでしょうが、今回はATAとしてインタフェイスを作成しているので、プライマリスレーブになりました。/dev/ada[n] は認識順に通し番号が振られるので、決め打ちで /etc/fstab 等に書いてる場合(このシステムでは swap が該当します)を考慮して、元のHDDの後の番号で接続するのが良いでしょう。

で、再起動。VirtualBoxのデフォルトのブート順はCD-ROMの方が先のようで、CDを入れると普通にインストーラが起動します。ここでは Shell を選択してコマンドラインに入ります。

以前 インストーラが CD-ROM やフロッピーで提供されていた時はコマンドラインで作業なんてのはあんまり現実的ではなかったのですが、現在は DVDで提供かつメモリが大きいのでメモリ上にファイルシステムを用意してコマンドライン上で普通に作業できるようになっています。

これを踏まえて新規に接続したハードディスク(ata1)にブートセクタを書き込んでいきます。

# gpart show ada1
gpart: No Such geom: ada1.
# gpart create -s GPT ada1
ada1 created
# gpart bootcode -b /boot/pmbr ada1
bootcode written to ada1
# gpart add -b 40 -s 512K -t freebsd-boot ada1
ada1p1 added
#gpart bootcode -p /boot/gptzfsboot -i 1 ada1

これで新規に追加したハードディスクにMBRと gptzfsboot が書き込まれました。このHDDから起動して、gptzfsboot が別ドライブのZFS を認識してくれるのなら起動するはずです。

VirtualBoxのBIOS画面で F12 を押すとブートメニューが起動します。

「Primary Slave」が今回追加したHDDなので、「2」キーを押します。

お?

おぉぉ!!

わーい、ちゃんと動きました。パチパチパチ。

ということで、gptzfsboot は別ドライブにあるZFSプールもちゃんと拾ってきてマウントしてくれるみたいです。HDDの不良セクタはどこに現れるかは運次第なのですが、ZFS Rootシステムだと初期の段階ではZFS領域に不良セクタが現れてもデータ欠損の可能性は低いですし、運悪くGPT管理領域だったとしてもGPTでは2つありますからよほど運が悪く無いとパーティションは壊れないような気がします。ブートコードが入っている場所が壊れて起動しなくなったとしても今回のように簡単に復旧できることがわかりましたので、メモリさえ潤沢にあるのなら、今やUFSよりもZFSの方が使い勝手が良いのかもしれませんね。

なお、上の例では追加のハードディスクを用意しましたが、「ブートセクタに不良セクタが出た」という場合、経験的には インストールDVDからShellを動かして

# gpart bootcode -p /boot/gptzfsboot -i 1 ada0

だけで不良セクタの代替処理が行われて起動するようになると思います。もちろんこんなところが死んでるハードディスクはその後すみやかに交換する必要があります。

余談ですが、インストーラが用意するようなZFS Rootの作成手順は下記の場所に書いてありました。

Installing FreeBSD 9.0 (or later) Root on ZFS using GPT
=https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/9.0-RELEASE

まだインストーラがZFSインストールに対応する前のドキュメントらしく、インストーラの途中でZFSファイルシステムを作成してからインストールするという手順が記載されています。現在のインストーラが行っている作業は概ねこの通りと考えてよいでしょうね。

そういえば、このドキュメント中に

Set atime to off, this avoid writing a metadata change every time a file is accessed, a serious performance penalty. It can also cause snapshots to grow unexpectedly.

という記述がありました。atime を off にすればスナップショットのサイズを抑制できるってのはわかりますが、「serious performance penalty」ですか。atime って普段は使わないけれど、キャッシュファイルを作成して使われてないのを削除するって場合には便利なのですが。どれくらい影響があるんでしょうねぇ。