ジャーナル・ファイル・システム (JFS) は、ログを用いた、バイト・レベルで管理を行うファイル・システムで、トランザクション指向の高性能システムを対象にして開発されました。拡張が容易で高信頼性を備えたこのシステムは、非ジャーナル・ファイル・システムよりも再始動が高速であるという利点があります。JFS は、数秒から数分でファイル・システムを整合性のある状態に復元します。

本来 JFS は高速なスループットと高い信頼性を必要とするサーバー向けに調整されていますが (シングル・プロセッサー・システムから高度なマルチプロセッサー・システムおよびクラスター・システムまで)、パフォーマンスと信頼性が要求されるクライアント構成にも適用することができます。

アーキテクチャーと設計

JFS のアーキテクチャーは、そのディスク・レイアウトの特性により説明することができます。

論理ボリューム

ファイル・システムの基本はすべて、ある種の論理ボリュームです。これは物理ディスクとするか、または FDISK パーティションなど物理ディスク・スペースのサブセットとすることができます。論理ボリュームは、ディスク・パーティションと呼ばれることもあります。

集合体とファイル・セット

ファイル・システム作成ユーティリティーの mkfs により、完全にパーティション内に含まれる集合体が作成されます。集合体は、スーパーブロックと割り振りマップを含む固有の形式を持つディスク・ブロックの配列のことです。スーパーブロックはパーティションを JFS 集合体として識別し、割り振りマップは集合体内の各データ・ブロックの割り振り状況を記述します。このフォーマットにはまた、初期ファイル・セットと、その記述に必要な制御構造も含まれます。ファイル・セットはマウント可能なエンティティーです。

ファイル、ディレクトリー、i ノード、およびアドレス指定構造

ファイル・セットは、ファイルとディレクトリーを含みます。ファイルとディレクトリーは、一貫して i ノードにより表されます。各 i ノードは、ファイルまたはディレクトリーの属性を記述し、ディスク上のファイルやディレクトリーのデータを検出するための開始点として機能します。また JFS は、割り振り状態を記述したマップや、ファイル・セット内の各 i ノードのディスク上の位置など、他のファイル・システム・オブジェクトを表すためにも i ノードを使用します。

ディレクトリーでは、ファイルとディレクトリーに割り振られた i ノードに対してユーザー指定の名前をマップし、従来型の名前階層を形成します。ファイルにはユーザー・データが含まれ、データ内には制約やフォーマットはありません。つまり、JFS においてユーザー・データは、未解釈のバイト・ストリームとして扱われます。i ノードをルートとするエクステント・ベースのアドレス指定構造は、ディスクへのファイルのマッピングに使用されます。集合体スーパーブロックとディスク割り振りマップ、ファイル記述子と i ノード・マップ、i ノード、ディレクトリー、そしてアドレス指定構造が一体となり JFS 制御構造あるいはメタデータを表します。

ログ

JFS ログは、各集合体内に保持され、メタデータ操作に関する情報を記録します。ログの形式は、ファイル・システム作成ユーティリティーによって設定することもできます。集合体内では、複数のマウント済みファイル・セットが、単一のログを同時に使用することができます。

上に戻る

設計上の特徴

当初より JFS は、既存のファイル・システムにジャーナリングを追加するのではなく、ジャーナリングを完全に統合する形で設計されました。JFS には、他のファイル・システムにはない特徴的な機能がいくつかあります。

ジャーナリング

JFS は、HPFS、ext2、および従来の UNIX ファイル・システムなどの非ジャーナル・ファイル・システムと比べ、構造の整合性と回復の可能性が改善され、再始動時間がより高速化されました。このような他の形式のファイル・システムは、論理的な書き込みファイル操作を完了するために複数のメディア入出力操作を要しますが、場合によっては書き込みの内容が完全にメディアに反映されないときもあるため、システム障害の際に破壊が起こることがあります。こうしたファイル・システムでは、再始動時のユーティリティー (fsck) を使用しなければなりません。これは、ファイル・システムのすべてのメタデータ (ディレクトリーおよびディスク・アドレス指定構造など) を検査し、構造の整合性の問題を検出および修復するものです。このプロセスは時間を浪費するばかりか、エラーの原因ともなり、最悪の場合はデータが消失したり、データの配置が不正確になる場合があります。

一方、JFS では当初から、ファイル・システムのメタデータに対して実行された操作情報を、アトミック・トランザクションとしてデータベースに記録するように開発されています。システム障害が発生したら、ログを再生して,該当するトランザクションのログ・レコードを適用します。こうして、ファイル・システムを整合性のある状態に復元します。このログ・ベースのアプローチにより、回復時間はかなり短くなります。これは、再生ユーティリティーが、ファイル・システムのメタデータすべてではなく、最新のファイル・システム・アクティビティーによって生成されたログ・レコードのみを検査するためです。

ログ・ベースの回復方法には、この他にも特徴があります。まず、JFS はメタデータへの操作しか記録しません。このためログを再生すると、ファイル・システム内の構造の関係とリソース割り振り状態の整合性のみが回復されます。ファイル・データを記録したり、そのデータを整合性のある状態に復元したりすることは行いません。そのため、回復後にファイル・データが失われたり無効となったりする場合があります。データの整合性が重要である場合は、入出力を同期させる必要があります。

メディア・エラーについては、ロギングが特に有効というわけではありません。特に、ログまたはメタデータをディスクへ書き込んでいる最中に入出力エラーが起きた場合はそうです。この場合、システム・クラッシュが起きてからファイル・システムを整合性のとれた状態に復元するには、整合性チェックを長時間、場合によっては他の作業を中断して、完全に行う必要があります。こうした点を見ると、JFS の元で動作する記憶管理プログラムおよびデバイスにおいては、不良ブロックの再配置機能が重要であることがわかります。

JFS のロギングの意味体系においては、メタデータの変更を伴うファイル・システム操作 -- unlink() -- が正常な戻りコードを戻すと、操作による影響がファイル・システムにコミットされ、システム・クラッシュの際でもこれを参照することができます。たとえば、ファイルが正常に削除された場合、このファイルは削除された状態のままとなり、システムがクラッシュして再始動した場合でも、復活することはありません。

このロギングの方式では、ログ・ディスクへの同期書き込みを、メタデータを変更する各 i ノードまたは vfs 操作において行います (データベース上級者向けに解説すると、これは redo-only、physical after-image、write-ahead ロギング・プロトコルで、スチールなしバッファー・ポリシーを使用しています)。パフォーマンスの面 でよい比較対象となるのは、メタデータの複数回の同期書き込みに応答することにより整合性を取る、一般的な非ジャーナル・ファイル・システムです。しかし、これは Veritas VxFS や Transarc Episode などのように、異なるロギング方式をとり、ディスクへのログ・データ書き込み回数の少ない他のジャーナル・ファイル・システムと比べると、パフォーマンスの点では不利になります。複数の並行操作が実行されるサーバー環境において、こうしたパフォーマンスの低下を抑えるには、グループ・コミット (複数の同期書き込み操作を単一の書き込み操作にまとめる) を行う必要があります。JFS のロギング方式は長年改良を重ねてきました。現在では非同期の記録を行うことにより、ファイル・システムのパフォーマンスを向上させています。

エクステント・ベースのアドレス指定構造

JFS は、効率的なブロック割り振りポリシーのほか、エクステント・ベースのアドレス指定構造を使用しています。コンパクトで効率のよい拡張容易な構造になっており、ファイル内の論理オフセットをディスクの物理アドレスにマップすることができます。エクステントは、1 つの単位としてファイルに割り振られた連続ブロックのシーケンスであり、＜論理オフセット、長さ、物理＞ の 3 つから記述されます。アドレス指定構造は、エクステント記述子 (上記の 3 点) により生成した B+tree です。i ノードをルートとし、ファイル内の論理オフセットをキーとしています。

可変ブロック・サイズ

JFS は、ファイル・システムごとに 512、1024、2048、および 4096 バイトのブロック・サイズをサポートし、ユーザーはそのアプリケーション環境においてスペース効率を最適化することができます。小さなブロック・サイズでは、ファイルやディレクトリー内の内部断片化を減らすことができ、スペース効率が向上します。ただし、小さなブロックの場合は、大きなブロック・サイズを使用した場合よりもブロック割り振り活動が頻繁に起こるため、パスの長さが増します。通 常、サーバー・システムでは、スペース効率よりもパフォーマンスが優先課題であるため、デフォルトのブロック・サイズは 4096 バイトとなっています。

動的ディスク i ノード割り振り

JFS は、必要に応じてディスク i ノードにスペースを動的に割り振り、不要となったスペースを解放します。従来のように、ファイル・システム作成時にディスク i ノードに固定スペース量を予約する必要がないため、ファイル・システムに含まれるファイルおよびディレクトリーの最大数を予測する必要もありません。さらにこの割り振りでは、ディスクの i ノードが、固定されたディスク位置から分断されます。

ディレクトリー編成

2 種類のディレクトリー編成が用意されています。第 1 の編成方法は、ディレクトリーが小さい場合に使用し、ディレクトリーの i ノード内にディレクトリー内容を保管します。このため、ディレクトリー・ブロックの入出力を分離する必要はなく、記憶域の割り振りも分離する必要がありません。最大 8 項目まで i ノード内にインラインで保管できますが、自身 (.) と親 (..) ディレクトリー項目は i ノードの別 領域に保管されます。

第 2 の編成方法はディレクトリーが大きい場合に使用し、各ディレクトリーは名前をキーとする B+tree として表されます。この方法は、従来型の未整列のディレクトリー編成と比べると、ディレクトリー検索、追加、および削除機能をより高速に行うことができます。

低密度ファイルと高密度ファイル

JFS ではファイル・システムごとに低密度ファイルと高密度ファイルをサポートします。

低密度ファイルでは、ファイル内のランダムな位置にデータが書き込まれます。書き込まれたデータとデータの間に存在する、未書き込みのファイル・ブロックをインスタンス化することはありません。報告されるファイル・サイズは、書き込まれた内の最大バイト数ですが、ファイル内のいずれのブロックについても、そのブロックへの書き込み操作が実行されるまでは、実際には割り振りは行われません。たとえば、低密度ファイル用のファイル・システムで新規ファイルを作成する場合を想定します。アプリケーションが、ファイルのブロック 100 にデータ・ブロックを書き込みます。JFS は、このファイルのサイズを 100 ブロックと報告しますが、実際にはディスク・スペースの 1 ブロックしか割り振られていません。次にアプリケーションがファイルのブロック 50 を読み取ると、JFS はゼロ充てんバイトのブロックを戻します。今度はアプリケーションがデータ・ブロックをファイルのブロック 50 に書き込む場合を想定します。この場合も JFS は、このファイルのサイズを 100 ブロックと報告し、2 ブロックのディスク・スペースが割り振られます。低密度ファイルは、必要な論理スペースは大きいにもかかわらず、実際には、その (小さな) サブセットしか使用しないアプリケーションにとって重要となります。

高密度ファイルの場合、ディスク・リソースはファイル・サイズを埋める形で割り振られます。上記の例では、最初の書き込み (ファイルのブロック 100 に対するデータ・ブロックの書き込み) により、ファイルには 100 ブロックのディスク・スペースが割り振られます。暗黙的に書き込まれたどのブロックを読み取っても、低密度ファイルの場合と同様に、ゼロ充てんバイトのブロックが戻されます。

上に戻る

内部的な JFS の (潜在的な) 制限

JFS は完全な 64 ビット・ファイル・システムです。該当するファイル・システム構造のフィールドはすべて、64 ビットのサイズです。これにより JFS は、ラージ・ファイルとラージ・パーティションをともにサポートします。

ファイル・システム・サイズ

JFS がサポートする最小のファイル・システム・サイズは 16 MB です。最大のファイル・システム・サイズは、ファイル・システム・ブロック・サイズと、ファイル・システムのメタデータ構造がサポートするブロックの最大数によって決まります。JFS のサポートする最大ファイル・サイズは 512 TB (ブロック・サイズは 512 バイト) から4 PB (ブロック・サイズは 4 KB) の範囲です。

ファイル・サイズ

最大のファイル・サイズは、仮想ファイル・システム・フレームワークがサポートする最大ファイル・サイズとなります。たとえば、フレームワークが 32 ビットしかサポートしない場合は、32 ビットがファイル・サイズの限界となります。

取り外し可能メディア

JFS は、基本ファイル・システム装置として、ディスケットをサポートしていません。.

上に戻る

標準の管理ユーティリティー

JFS には、ファイル・システムを作成および保守するための、標準管理ユーティリティーが用意されています。

ファイル・システムの作成

このユーティリティーには、mkfs コマンドの JFS 固有の部分が備えられています。つまり、指定ドライブ上で JFS ファイルを初期化することが可能です。このユーティリティーは低レベルで動作します。ファイル・システムの配置先となるボリュームの作成/初期化は、ユーティリティー外部の上位 レベルで行われることを前提としています。

ファイル・システムのチェック/回復

このユーティリティーには、fsck コマンドの JFS 固有の部分が備えられています。これは、ファイル・システムに整合性があるかどうかをチェックし、問題が見付かれば、それを修復します。また、ログの再生を行い、コミット済みの変更をファイル・システムのメタデータに適用することも行います。ログ再生の結果 、ファイル・システムがクリーンであると宣言されると、それ以上のアクションは行われません。ファイル・システムがクリーンでないと判断された場合 (何らかの理由でログがすべて正しく再生されない、またはログを再生しただけではファイル・システムを整合性のある状態に復元できない)、ファイル・システムの全走査が行われます。

整合性の完全チェックを行う際の、チェック / 修復ユーティリティーの最初の目標は、ファイル・システムの信頼性を確かなものにして、その破壊や障害を予防することです。破壊が起きた場合のデータ保護は、その次の目標となります。したがって、ユーティリティーがファイル・システムの整合性を保持する際に、データが破棄されることがあります。特に、構造に整合性のないファイルやディレクトリーを、前提事項なしに、整合性のある状態に復元しようとする場合、そのために必要な情報がなければ、データが破棄されることになります。ファイルやディレクトリーに整合性がない場合は、それら全体が破棄され、部分的に保管されることはありません。破壊されたディレクトリーを削除することにより孤立したファイルやサブディレクトリーは、ファイル・システムのルートにある lost+found ディレクトリーに配置されます。

ファイル・システムのチェック/修復ユーティリティーについての重要な考慮事項として、必要とする仮想メモリー量 があります。従来の方式では、このようなユーティリティーが必要とする仮想メモリー量は、ファイル・システム・サイズに依存していました。必要とされる仮想メモリーの多くが、ファイル・システムの個々のブロックの割り振り状態を追跡するために使用されるからです。ファイル・システムが拡大するにつれ、ブロック数が増し、それに伴い、これらのブロックの追跡に必要な仮想メモリー量 も増加します。

JFS のチェック/修復ユーティリティーはこれとは異なり、ブロック数ではなく、ファイル・システム内のファイルとディレクトリーの数により仮想メモリー要件が決まります。JFS のチェック/修復ユーティリティーの仮想メモリー要件は、ファイル・システムのサイズに関係なく、ファイルまたはディレクトリーあたり 32 バイト、またはファイル・システム ( 100 万のファイルとディレクトリーを含む) あたり約 32 MB の条件に従います。他のすべてのファイル・システムと同様に、JFS ユーティリティーもブロックの割り振り状況を追跡する必要がありますが、その場合、仮想メモリーを使用せずに、実際のファイル・システム内に配置されたわずかな予約作業域を使用します。

上に戻る

要約

JFS は、システム・クラッシュ時のファイル・システムの再始動を高速化できるという点で、インターネット・ファイル・サーバーにおけるキー・テクノロジーと言えるでしょう。JFC では、データベースのジャーナリング技法を用いることにより、数秒から数分で、ファイル・システムを整合性のとれた状態に復元することができます。非ジャーナル・ファイル・システムでは、ファイルの回復に数時間あるいは数日要する場合があります。しかし、これほどの時間、システムがダウンしてしまうようでは、ほとんどのファイル・サーバーのユーザーには受け入れてもらえないでしょう。整合性を確立するために、ファイル・システムの全メタデータを検査して、ファイル・システムを検証 / 復元するというプロセスは、大変に時間がかかります。こうした問題を解決する手段は、ただ一つ。ジャーナリング・テクノロジーを導入すること以外にはありません。

著者について

この記事を評価する

コメント

上に戻る

目次

• アーキテクチャーと設計
• 設計上の特徴
• 内部的な JFS の (潜在的な) 制限
• 標準の管理ユーティリティー
• 要約
• 著者について
• コメント