FreeBSD 7.0-RELEASEではファイルシステムとして新たに，UFS2をジャーナリング機能で高速化する「GEOM journaling」や，OpenSolarisからの移植である「ZFS」が利用できるようになった。これらの新機能はFreeBSDのポリシーに従って，安全性・安定性が確保できるまではオプション扱いであるが，筆者も含めた新しいもの好きにとっては新機能は速攻試したくなるのが人情である。結果，どちらも魅力的で今後FreeBSDでの標準が動く可能性も十分ありうるという印象を得たので報告する。

ファイルシステム発展の歴史－soft updatesとjournaling

FreeBSD 7.0-RELEASEで標準採用されているファイルシステムはUFS2といい，5.1-RELEASEから標準となった「UFS2」と4.5-RELEASEから標準となった「soft updates」との組み合わせで動いている。UFS2に至る歴史は，たとえば技術評論社『FreeBSD Expert』への筆者による寄稿※1 などを読み返して軽くおさらいしてもらうとして，ファイルシステムの進歩の歴史は常に，

• 大容量化に対応したアクセス速度の高速化: スピード
• ファイルシステムの完全性（filesystem integrity）: 安全性

との，両立しない二つの指標をいかにバランスさせるかに知恵が使われていることを頭に入れておこう。ファイルシステムは，実際のデータと，データに関する情報（ディレクトリやユーザ情報など）であるメタデータから構成されており，特にメタデータ更新の出来不出来で，ファイルシステムは安全にも危険にも，高速にも低速にもなりうるのである。

※1

「安心，安全，UFS」三田吉郎／『⁠FreeBSD Expert 2004』p.50（特別企画1，第1章⁠）⁠／技術評論社／ISBN4-7741-1953-9

一般ユーザがファイルシステムに依存したディスク書き込み性能の限界をを体感できる時は，「⁠ports.tgz展開」のように，ファイルを無数に展開する時である（一方，2Gバイトといった大容量のファイルをコピーする時間は，ハードウェア自身の性能の限界を示している⁠）⁠。データ書き込みは必ずメタデータ情報の更新を伴なうが，更新するべきメタデータの数はファイルの数に比例して増加するので，メタデータ更新のオーバーヘッド分だけ手間が増加して時間がかかる。日頃の生活でも，細切れの仕事が増えれば増えるほど，仕事に取りかかるまでの下準備期間が足枷となって，全体の処理能力が低下することは筆者ならずとも一度は体験したことがあると思う。

日常生活の連想で処理スピードを向上させる方法を考えると，

• 細切れの仕事をまとめて一気に仕上げる
• 仕事をやった振りをして空いている時間に実行する

方法を思いつく。実際「非同期（asynchronous）書き込み」と呼ばれる方法はこの戦略を取っている。すなわち，データが一定の大きさにまとまるまでメモリ上に「溜めておき⁠」⁠，定期的に「後から書き込む」という仕組みである。表1のように，asyncオプションでマウントしたディスクは圧倒的に高速である。

ところがこの戦略，うまくいっているうちは良いが，もし事故でもあって「仕事をやった振りをして後からやろうと思っているうちにデータを紛失」しようものなら取り返しが付かなくなる。「⁠すみませんがハードディスクが飛んでしまって云々」と方々に言い訳して仕事の割り振りをやり直す羽目になる。もしも無くしたデータが「お金の振込先リスト」だった場合を想像してもらいたい。詐欺の格好の餌食になってしまうであろう。

FreeBSDはこのような，突然電源が切れるなど，不測の事態が起こったときにもファイルシステムの完全性を保てること，具体的には全ての瞬間で，どこまでのメタデータが正常で，どこからが正常でないかを切りわけられることをインテグリティ（integrity）と呼んで重要視している。このファイルシステムインテグリティが保てないと，システムの予期せぬ終了の後，いきなりファイルが他人のものになったり，1つのファイルが2つのオーナーに化けたりすることが考えられ，セキュリティ上重大な問題となる。

特に，データの書き込み途中で電源が切れた場合，このような問題が起こりうるわけで，4.6-RELEASE以前のFreeBSDでは遅いが最も安全な「同期書き込み」（⁠データが来た時点でディスクに書き込む）方法を使っておいたが，4.6-RELEASE以降では遅延書き込みのもう一つの方法として，「⁠soft updates」という方式を採用したのである。soft updatesは，たとえばデータを更新するときに，

1. まっさらの領域に実体のデータとメタデータの領域を確保し
2. データとメタデータが完全に用意できた時点で
3. 新しい実体へのポインタを張り直す

という戦略を取っている。この手法を使えば，メタデータを作成して書き込み待ちの途中に電源が突然切れたとしても，どこからも参照されていないメタデータがディスクに残るだけなので，「⁠fsck」プログラムによって，ゆっくりとこのゴミを取り除けばよい。このようにしてファイルシステムの完全性は何時も保ったまま，実際のディスクにはまとめて後から書き込むという戦略のお蔭で，ファイルシステムの完全性を保証したまま，同期書き込みに比べて1.5倍の速度向上を実現したのである。

FreeBSDでは現在までのところ，UFS2とsoft updatesの組み合わせが，ファイルシステムの完全性を常に保った上で，なおかつファイル生成削除時に体感できるメタデータ更新のスピードとのバランスが最も良く取れているということで，しばらく（少なくとも4年間）の間標準の座を不動のものとしている。確かにUFS2＋soft updates，さらにバックグラウンドfsck三羽烏で颯爽と登場した5.1-RELEASEに接したとき，「⁠UFS最強」と筆者も思ったものである。この最強トリオに打ち勝って標準を取るにはよほどのメリットが必要とされるので，新機能の開発者には辛いハードルであると同時に，ハック冥利に尽きるというものである。

本稿で紹介するGEOM journalingは，「⁠これから行うメタデータ変更の予定を日誌（journal）に書き出しておいて，ジャーナルの記入が終了したところで実際のデータ更新を行う」という方針である。記入が終わっていないjournalのパートを単純に無視することで完全性を保証できる（ZFSも同上の方針である⁠）⁠。この方式の最大のメリットは，突然のシステム停止から再起動をした後でもfsckをかける必要がないことである。7.0-RELEASEではシステムを働かせながらファイルシステムのチェックを行う，background fsckが標準であるので，マシンが異常終了してから再起動するまでの待ち時間は正常時とほとんど変わらないとはいいながら，fsck中のあのハードディスクのガリガリ時間が嫌な読者には朗報であろう。

UFS2+GEOM journalingを使ってみよう

GEOM journalingについてのまとまった論文はまだなく，マニュアルページ，開発者のPawel Jakub Dawidek氏のメール，またはソースコードなどが手掛りになる。

# man gjournal

で予習をすると，

• 新しいディスク上での利用（newfsフォーマットする）
• 既存のファイルシステム上で応用（newfsフォーマットしない）

の2つのやり方があると書いてある。FreeBSDを使っている読者にとっては当然，既存のファイルシステム上での応用が魅力的なわけだが，手順を1つでもしくじるとデータは戻ってこないので注意が必要である。実際筆者も手順をしくじってスライスを1つ飛ばしてしまったので特に注意を喚起しておきたい。ハードディスクの容量は右肩上り，値段は右肩下りなので，ここは1台新品のディスクを奮発して，本特集第2回「7.0-RELEASEでディスク丸ごとバックアップ」で紹介した方法などを使って「丸ごとバックアップ」を取ってから試すことをお勧めする。

筆者が用意したディスク（ad4，Hitachi HDT725040VLA360/SATA150）には，ad4s2，ad4s3に3つのパーティションが切ってあり，そのうちad4s3eを/home2として使い，ad4s3fが未使用である（正確には/home3だった領域をミスで壊してしまったわけだが…⁠）⁠。この状況で，

• ad4s3fにjournalingのスライスを新規作成
• ad4s3fをjournalとして，既存スライスad4s3eのジャーナリングを行う

という2つの方法を試してみることにしよう。