ユーティリティ
JFSには、ファイルシステム管理用ユーティリティが一式用意されている。これらのユーティリティを使用するためにはルートユーザになる必要がある。
| ユーティリティ | 説明 |
|---|---|
| jfs_debugfs | シェルベースのJFSファイルシステムエディタ。ACL、uid/gid、モード、時刻などを変更することができる。ファイルの中身を変更することもできるが、その場合は16進数で入力しなければならない――ファイルの編集に使うにはあまり効率良くはないだろう。 |
| jfs_fsck | JFSのトランザクションログを再生して、JFSファイルシステムのチェック/修復を行なう。マウントされていない状態のファイルシステムか、読み取りのみ可のファイルシステムに対してのみ実行されるべき操作。ブート時に自動的に実行される。 |
| jfs_fscklog |
JFS fsckサービスのログをファイルに書き出す。「jfs_fscklog -e /dev/hda6」を実行すれば、バイナリのログをfscklog.newという名前のファイルに出力することができる。「jfs_fscklog -d fscklog.new」を実行してファイルを閲覧することができる。
|
| jfs_logdump | ログファイル内の各トランザクションのデータを示すプレーンテキストのファイルとして、ジャーナルログを出力する。 |
| jfs_mkfs |
パーティションをJFS形式でフォーマットする。「-j journal_device」というオプションを使用すれば、外部ジャーナルを作成することができる（1.0.18以降）。
|
| jfs_tune |
JFSの調整可能なパラメータを調整する。性能を向上させることができそうなオプションは私の場合は見つからなかった。「-l」オプションを使用すればスーパーブロック情報を見ることができる。
|
スーパーブロック情報がどのように表示されるのかを以下に示す。
root@slackt41:~# jfs_tune -l /dev/hda6 jfs_tune version 1.1.11, 05-Jun-2006 JFS filesystem superblock: JFS magic number: 'JFS1' JFS version: 1 JFS state: mounted JFS flags: JFS_LINUX JFS_COMMIT JFS_GROUPCOMMIT JFS_INLINELOG Aggregate block size: 4096 bytes Aggregate size: 12239720 blocks Physical block size: 512 bytes Allocation group size: 16384 aggregate blocks Log device number: 0x306 Filesystem creation: Wed Jul 11 01:52:42 2007 Volume label: ''
復旧テスト
ホワイトペーパやマニュアルページだけでは分からない厳しい現実がサーバ室にはあるものだ。そこでJFSの復旧能力を試すために、負荷をかけた状態で（強制電源オフにより）システムをクラッシュさせてみた。なお妥当な結果を得るために、クラッシュはそれぞれ2回ずつ行なった。
| クラッシュ時の負荷 | 復旧 |
|---|---|
| ファイルを1個開いたテキストエディタを実行中のコンソール（Xは起動せず） | ジャーナルログの再生に約2秒。エディタ上で保存しておかなかった変更は失われたが、ファイルは損なわれていなかった。 |
| Xウィンドウシステム上のKDE、それぞれファイルを開いた状態のGIMP、Nvu、xterm上のテキストエディタ | ジャーナルログの再生に約2秒。どのファイルも完全な状態だったが、保存していなかった変更は失われた。 |
| Xウィンドウシステム上のKDE、それぞれファイルを開いた状態のGIMP、Nvu、xterm上のテキストエディタ、MySQLのテーブル（ISAM）にレコードを挿入するシェルスクリプト。スクリプトは自作のもので、無限ループ。レコードがディスクにフラッシュされ始めるまで2、3分間実行した。 | ジャーナルログの再生に約3秒。開いておいたどのファイルも完全な状態だった。2000～3000個のレコードが挿入された状態のデータベースも損なわれていなかった。ただしテーブルファイルのタイムスタンプが1分前のものになっていた。 |
上記のすべてのケースで、以下のようなブートメッセージが表示された。
**Phase 0 - Replay Journal Log -|----- (spinner appeared for a couple of seconds, then went away) Filesystem is clean
クラッシュを何回も行なったが、ファイルシステムの崩壊は一回も起こらなかった。またログの再生にかかった最も長い時間は約3秒だった。
まとめ
上記の即興の復旧テストは、負荷の高いサーバのシミュレーションとしては不十分ではあるが、JFSは問題なくテストに合格し、復旧も高速だった。tarやrsyncなどのファイルアクセスの激しいアプリケーションも試してみたが、どのアプリケーションもまったく問題なかった。またTruecryptなどのより下層を取り扱うプログラムも試したが、期待通りに動作した。
30日間あれこれやってみた結果、私はJFSを高く信頼するに至り、安心して自分のデータを任せている。JFSはこれまで他の選択肢ほど上手に宣伝されてこなかったかもしれないが、数多くの高品質なLinux用ファイルシステムの中においても堅実な選択肢の一つだと言えるだろう。