少なくとも /boot には UFS を使う必要がある現在、ファイルシステムを完全にZFSに切り替えるのは時期尚早ではあるのですが、そうしたくなるくらいの魅力がZFSにはあります。てことで、前回からさらに遊んでみてわかったことをいくつか羅列。
- マルチユーザ/シングルユーザモードの切り替え時は呪文が必要
- 実際に切り替えてみると
ZFS: WARNING: pool 'tank' could not be load as it was last accessed by another system (host: hostid: 0x9386a05). See: http://www.sun.com/msg/ZFS-8000-EY
などのように表示されて自動マウントされません。-f オプションを使って import すれば問題ありませんが、ZFS ROOT な環境でマウントが阻止されたらコマンドを実行する手段がないのでは? とか心配になります。
↑ mountpoint=legacy とすれば問題ないことがわかりました
- compress=onで割と小さくなる
- 自宅サーバで使っているルートファイルシステムをリストアしてみたところ、compress=off: 5,800(MB) に対して compress=on: 1,900(MB)という結果になりました。もちろんcompress=onはパフォーマンス低下とCPU負荷増加を招きますが、うまく使えばディスク領域を有効利用できます。FreeBSDでは圧縮をサポートするファイルシステムはZFSが初めてではないでしょうか。
- UFSからの移行にはrestoreが使える
- ZFSのバックアップやリストアは zfs send/receive を使うみたいなのですが、UFSで運用中のシステムは通常dumpでバックアップをとっています。ZFSでdumpが使えるかどうかはしりませんが、とりあえずrestoreは正常に動作するようです。
- attach/detachにてHDDの増量が可能?
- ちょっと情報不足なのですけど。ZFSの仕様ではmirrorデバイスは同容量じゃなくても良いみたいで、単純に一番小さい容量分しか使われないので無駄になると。そこで、たとえば100GBのディスクをストレージプールとして使っている時に200GBのディスクをattachしたとします。当然100GBしか使われずにリビルドが開始されるのですが、リビルド後に100GBのディスクをdetachしたらどうなるのだろう? ということですね。コマンドが問題なく実行できるのなら面倒な手続き無しでHDD容量を増量できるのかな? 手元に適当なHDDが無いので試せませんがそのうち実験してみたいです。
- 冗長化の選択肢が多い
- 2または3以上のドライブを用いたmirror、RAID5のような形式のraid-z、データをいくつかの場所に重複して保存する copies オプションなどを用途に応じて使い分けられます。特に copies の発想は通常のファイルシステムには無いですな。ノートパソコンのHDDにきわめて重要なデータやプログラムを置く時なんかに良いだろうなーと思います。
- エラー発生時に修復を試みてくれる(らしい)
- ハードディスクって長く使ってると不良セクタができます。このセクタって数が少なければHDDが元から用意してある代替セクタを用いて修復可能なわけですが、ZFSでは冗長化しているデータの読み込みエラーが起きたときは自動的に修復作業をしてくれるのだとか。これもちょっと調べてみないとなんとも言えませんが、そういう動作をするのならとてもありがたいです。
という感じ。ZFSのmirrorはとても分かりやすいのですが、残念ながらZFS ROOTではスライスを切って扱うことになるので、gmirrorのようにドライブ全部をミラーすることができません。解決策としてはdisklabelや/boot領域を手作業でミラーリングしたり、あるいは/boot領域用に起動専用のドライブを用意するといったところでしょうか。どちらもあんまりスマートじゃないですな。なんとか ZFS Boot が実現可能にならないかな～と思います。
□ 関連記事