進化し続けるReiserFS：Linuxファイルシステム技術解説（5）（2/2 ページ）

Linux用ジャーナリングファイルシステムとしては古参ともいえるReiserFS。そのアルゴリズムや新バージョン「Reiser4」の機能について解説する。（編集局）

[菅谷みどり，＠IT]

ReiserFSのジャーナリング

　ReiserFSは、開発の早い段階からジャーナリング機能が実装されていた。ReiserFSのジャーナリング機能は、基本的にext3と同様にメタ・データを保存する。

■トランザクション処理

　ReiserFSでも、ext3のジャーナリング処理と同様に「トランザクション」単位で処理を行っている。また、ReiserFSのジャーナリングはext3のorderingに当たる方式のみをサポートしている（注）。

注：メタ・データのジャーナリングのみを対象とし、データはジャーナリングの対象としない方式。ext3のジャーナリングとトランザクション処理については第4回参照。

　writeやreadの呼び出し時に、内部的にジャーナリング処理の開始命令であるjounal_begin機能を呼び出してメタ・データをロギングし、処理の終了時にjounal_endを呼び出して実際のコミットまでの処理を行っている。トランザクションごとに行われるジャーナリング処理では、ディスクリプションブロック、データブロック数やコミットブロックを管理し、それらが連続的に書き込まれることが保証されるようにしている。

■バッチ処理

　ReiserFSには、複数のトランザクションを1つのアトミック処理としてまとめるバッチ処理がある。例えば、トランザクション1がブロックA、B、Cをロギングし、トランザクション2がブロックA、C、Dをロギングした場合、バッチ処理ではトランザクションを統合し、A、B、C、Dを一緒にしてコミットする。

　バッチ処理はトータルの書き込みブロック数を減らす効果があるが、ブロックをメモリに保持する時間が長くなればクラッシュ時に変更が正確に反映されない可能性も生じる。ReiserFSでは、この対策としてバッファのフラッシュ時間の調整が望ましいとしている。bdflushでフラッシュの値をチューニングするとよいだろう。

■非同期コミット

　非同期コミットはバッチ処理の拡張ともいえる機能で、ログブロックをその都度ディスクにフラッシュせずに、ある程度時間を置いてから非同期にディスクに書き込む。ext3と同様に、bdflushなどによるフラッシュが行われる。

　現在のReiserFSのジャーナリングでは、固定した場所にあるログにジャーナルを記録している。しかしこれは、物理的に離れた位置にファイルがある場合は、書き込みのためのオーバーヘッドが大きくなるという問題がある。さらに、ジャーナリングを必要としないアプリケーションの場合、ジャーナリング処理のオーバーヘッドが無駄である。

　Reiser4はこれに対して、ログやコミットの領域の場所としてそれぞれ最適な場所を選択する方式（注）の開発が進んでいる。

注：Dave Hitz氏がネットワーク機器で成功したWAFL（Write Anywhere File Layout filesystem）。

そのほかReiser4の改善点

　これまでも折に触れてReiser4の改善点について述べてきた。ここでは、そのほかの主な改善点について紹介する。

■リパッカー

　ディスク上にあるファイルの約80％は長い間変更されることはない。ReiserFSでは、この変更されないファイルを最適な位置に詰め直す（リパック）ことで、ディスクのスペースを増やす操作を行っていた。しかし、きっちりとリパックし過ぎると、ファイルが修正されてディスクブロックが追加された場合などに、そのファイル以降のデータをすべて移動し直すといった非効率的な処理が生じていた。

　Reiser4ではこの点を改善し、空きファイルを適度に挿入することで全部のデータを移動するといった無駄が生じないようにしている。

■プラグイン

　Reiser4では、ファイルシステムに必要な機能をプラグインとして実装することにより、機能を簡単に拡張・削除できる。標準では、表2の機能がプラグインとして提供されている。

ファイルプラグイン	すべてのファイルにプラグインIDを付与し、操作に関するメソッドを提供する
ディレクトリプラグイン	すべてのディレクトリにプラグインIDを付与し、操作に関するメソッドを提供する
ハッシュプラグイン	ファイル名をハッシュして、キーを生成するのに利用される
セキュリティプラグイン	ファイル／ディレクトリプラグインから呼び出され、「ファイルがプラグインIDを持っているか」「read／write権限を保有しているか」など、セキュリティにかかわるすべての操作をチェックする
アイテムプラグイン	アイテム操作に関するメソッドの提供
キー配置プラグイン	ポリシーに従って正しいキーを作成する
検索プラグイン	レイアウト内での検索のメソッドを提供
表2　Reiser4のプラグイン

　新しいプラグインをReiser4に追加する場合は、カーネルをリコンパイルする必要がある。

■セキュリティの強化

　RiserFSは今後、セキュリティを強化する方向で開発が進められている。セキュリティに詳細な注意を払うために、トランザクションに対してセキュリティチェックを導入する方針である。

■名前空間の考え方

　ReiserFSの中心的なコンセプトの1つとして、名前空間の統合（unified name space）がある。これは、名前と実態とを空間内で一致させることにより、名前が示すオブジェクトを扱いやすくすることを志向した考えである。

　例えば、User1というユーザーがいた場合、user1/mailはメールの受信箱、uesr1/mail/message-ID/[e-mail]がメール本文、user1/mail/message-ID/[e-mail]/toがToフィールドの値、user1/mail/message-ID/[e-mail]/fromがFromフィールドの値というように、ファイルシステム内のディレクトリ／ファイル構造に保存できるようにする。

　もし仮に上記の仕組みに対応したメールソフトを作成したとすると、ユーザーのメールボックスから対応するmessage-IDのメールを取得すればよいので、

User1.getMailBox().getMessageByID（"user1/mail/message-ID/[e-mail]"）

のように、オブジェクト指向を利用して記述できる。

　このように、ReiserFSではファイルシステムのディレクトリ／ファイル構造の中にオブジェクト指向を導入することで、ファイルシステム上のプログラミングを容易にすることを目指した。しかし現段階では、このコンセプトは実現されているとはいい難い。だが、プラグインの考え方もこのような指向が反映された結果といえるだろう。実際、セキュリティの機能拡張などに生かされていくようである。

　こうした方向性も十分に注目できるファイルシステムである。

ReiserFS関連コマンド

　最後に、ReiserFS関連のコマンドを紹介する。

■ファイルシステムの作成とマウント

　ReiserFSの作成は、mkreiserfs、mkfs.reiserfs、mkfs -t reiserfsコマンドで行う。

# mkreiserfs /dev/hda4　≪←mkfs.reiserfsでも同じ≫
<-------------mkreiserfs, 2002------------->
reiserfsprogs 3.6.4
mkreiserfs: Guessing about desired format..
mkreiserfs: Kernel 2.4.20-8 is running.
Format 3.6 with standard journal
Count of blocks on the device: 5054450
Number of blocks consumed by mkreiserfs formatting process: 8366
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: a65ba660-7b10-40ae-aabe-22a1acc7b62f
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
        ALL DATA WILL BE LOST ON '/dev/hda4'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok
....<messages>....

　mkreiserfsコマンドでは、ジャーナリングするデバイス、ファイル、デバッグ情報の表示の有無などをオプションで指定できる。

　マウントはmountコマンドに-t（タイプ）でreiserfsを指定する。

#mount -t reiserfs /dev/hda4 /data
#df -T
/dev/hda4 reiserfs    20217176     32840  20184336   1% /data

■クラッシュ時のfsck

　ReiserFSがクラッシュなどにより破壊されてしまった場合は、reiserfsckでファイルシステムのチェックを行うことができる。このコマンドは、ジャーナリングに記録された必要なトランザクションを再現する。また、ファイルシステムのチェック、修復を行う。

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck --check started at Sun Aug 31 17:39:33 2003
###########
Replaying journal..
trans replayed: mountid 10, transid 13, desc 30, len 2, commit 33,
 next trans offset 16
trans replayed: mountid 10, transid 14, desc 34, len 2, commit 37,
 next trans offset 20
trans replayed: mountid 10, transid 15, desc 38, len 3, commit 42,
 next trans offset 25
3 transactions replayed
Checking internal tree..finished
Comparing bitmaps..finished
Checking Semantic tree:
finished
No corruptions found
There are on the filesystem:
        Leaves 1
        Internal nodes 0
        Directories 1
        Other files 3
        Data block pointers 0 (0 of them are zero)
        Safe links 0
###########
reiserfsck finished at Sun Aug 31 17:39:36 2003
###########

　reiserfsckコマンドにはさまざまなオプションがある。ファイルシステムの状態チェックのみを行いたい場合は、以下のようにする。

# reiserfsck --check --logfile check.log /dev/hda1  reis-erfsck --check  0

　reiserfsck --checkを実行した際、結果がステータス1の場合（修正可能な壊れたデータが存在「corruption that can be fixed with --fix-fixable」が表示される）は、-fix-fixableオプションで回復できる。このオプションは、スーパーブロック情報を復旧せずに修正できる壊れたデータを復旧する。

# reiserfsck --fix-fixable  --log-file fixable.log /dev/hda1

　reiserfs -checkで致命的に壊れたデータが存在することが分かった場合は、--rebuild-treeオプションを実行する必要がある。

# reiserfsck --rebuild-tree

　ただし、このコマンドはスーパーブロック情報の修正を試みる危険な操作を行うため、パーティション全体のバックアップを取っておく必要がある。この操作が失敗した場合は、ぜひバグレポートで報告してほしいとのことである。

■デバッグ

　ReiserFSのデバッグには、debugreiserfsを使う。debugreiserfsコマンドをそのまま実行すると、ファイルシステムの状態についての情報を表示する。

■ファイルシステムの回復

　debugreiserfsに-pオプションを付けて実行すると、メタ・データのスナップショットを保存できる。このスナップショットは、バックアップやファイルシステムの復旧に利用できる。reiserfsckでfsckをかけてもファイルシステムが復活しない場合は、デバイスのメタ情報のスナップショットを取得し、それを後に展開することで以前のファイルシステムの状態を復元できる。

# debugreiserfs -p /dev/hda4 | gzip -c > metadata.gz
<-------------debugreiserfs, 2002------------->
reiserfsprogs 3.6.4
Loading on-disk bitmap .. 8366 bits set - done
super block..ok
bitmaps..(155).. ok
journal (from 18 to 8210)..ok
Super block, bitmaps, journal - 8349 blocks - done, 17 blocks left
0%....20%....40%....60%....80%....100%                           
left 0, 0 /sec
Packed 8350 blocks:
        compessed 7
        full blocks 8343
                leaves with broken block head 0
                corrupted leaves 0
                internals 0
                descriptors 0
data packed with ratio 1.00

　いったんディレクトリの削除などを行った場合も、ファイルシステムのスナップショットをgunzipで展開すれば、元のファイルシステムの情報が復旧できる。スナップショットを定期的に実行するようにcronなどの設定を行えば、ファイルシステムのバックアップとしても利用できる。

# gunzip -c metadata.gz | unpack /dev/hda4
<-------------unpack, 2002------------->
reiserfsprogs 3.6.4
There were 5054450 blocks on the device
..........................................................
..........................................................
..................................................Unpacked 7 leaves,
 8343 full blocks
Temp file opened by fsck: ".bitmap" ..

「次回」へ

「Linuxファイルシステム技術解説」バックナンバー

• 64bitファイルシステム XFSの実装
• JFSのファイル管理とジャーナリングの実装
• 進化し続けるReiserFS
• ext3とトランザクション処理
• ジャーナリングファイルシステムが保護する「情報」
• ブロックアルゴリズムとB-Treeアルゴリズム
• VFSとファイルシステムの基礎技術