Mac OS Xにおけるファイルシステム事情～ジャーナリングが齎すシステム可用性への貢献～

前回の「Mac OS Xにおけるファイルシステム事情～32bitファイルシステム「HFS Plus（Mac OS拡張フォーマット）」に引き続き、今回は「Mac OS X（Server）10.2.2」より導入され、HFS Plusに信頼性と可用性の向上を齎す「ジャーナリングファイルシステム」を紹介したいと思います。

●トランザクション処理とジャーナリングファイルシステム

今回紹介する「ジャーナリングファイルシステム」は、Linuxベースのサーバオペレーティングシステムや「BeOS（BeFS）」等における採用実績を有している他、「Windows 2000」以降において標準的に使用されている「NTFS（NT File System）」でもサポートされている等、現在ではサーバ用途の環境のみならず、クライアント環境においても主流として採用されているファイルシステムの１つで、コンピュータシステムにおける信頼性評価の指標とされる「RASIS」（注１）の「A」、Availability（可用性）を重視した仕様となっています。データベースサーバでは古くから標準的に採用されている実績もあり、基本的な仕様の中では、ファイルやフォルダ等のディスク上における各種リソースに対して「追加、更新、削除（SQLにおける「INSERT」「UPDATE」「DELETE」）」等のアクションが発生した際に、ファイルシステムにおける一連の更新履歴をメタデータの一種でもある「ジャーナルファイル（ログファイル）」に継続的な変更記録として保持させる事が大きな特徴の一つとして挙げられます。元来、BSD UNIXベースの「Darwin」を基盤とし、「プリエンプティブマルチタスク」「メモリ保護」等といったモダンOSに必須とされる機能を標準装備しているMac OS Xは、不安定なOSの代名詞とまで揶揄されていたClassic Mac OS時代の汚名を完全に払拭する程のシステムの安定性と信頼性を実現するに至っていますが、それでもデバイスドライバの不具合等による不慮のクラッシュ等に見舞われる事が無いとは言い切れないのが現状です。そして、そのような事故や停電を始めとする不慮の電源断、強制再起動、或いはシステム障害等といった不正終了を引き起こすトラブルに見舞われた場合に、前述のジャーナルファイルを有効活用しつつ、ファイルシステムの不整合や、システムのダウンタイムを最小限に抑えようとする主旨の基に開発されたのが、ファイルシステムにおけるジャーナリングの特徴となっており、このあたりはデータ自体に対する保全性（Integlity）の確保を重視したデータベースサーバ上のジャーナリングとは若干ニュアンスが異なっています。

そして、このジャーナリングを説明しようとする場合には「トランザクション」という用語が一つのキーワードとなりますが、これは広義において「処理」を意味する言葉であり、データベースを始めとするコンピュータ関連では、

「１つのJobに対して実行される、関連性のある複数のアクションが１つのまとまりとなった処理単位」

として扱われる事が多くなっており、このトランザクションはその性質上、

「１つのトランザクション（一連の処理）を完全に終了させる（コミット）」か、
「一連の処理の途中で中断が起こった場合（不慮、意図的を問わず）には、全ての処理を無効とし、更新前の状態に戻す（ロールバック）」

の何れかの状態しか許されません。そしてトランザクションを処理するシステムにおいては、未確定な処理や別のトランザクションによる介入等が発生すると、更新結果に対する矛盾やファイルシステムにおける不整合を招く要因と判断されるため、

「１つのトランザクションによって参照されているデータは、他のトランザクションから参照する事はできても、更新する事はできない（共有ロック）」或いは、
「１つのトランザクションによって更新されているデータは、他のトランザクションからは参照する事も更新する事もできない（占有ロック）」

といった排他制御によるアクセスコントロール（後に説明する隔離性（Isolation）にも通じる）が行われる事となります。そしてこれらの性質を満たすために、トランザクションには以下の４つの特性が求められる事となります。

原子性（Atomicity）

先に紹介した、トランザクションを構成する一連の処理による結果（全て有効か、或いは全て無効かの何れかしか有り得ない）を保証する性質。全てのトランザクションはコミットかロールバックの何れかの処理しか許されないといった事を意味しており、ジャーナリングの基本理念を示した性質といえる。尚、Atomicityによる性質を反映させた処理は「アトミック処理」と呼ばれている。

一貫性（Consistency）

トランザクションによって処理されたデータの、実行前後における整合性と一貫性の保証、データベースにおける矛盾の排除。

隔離性（Isolation）

先に挙げた排他制御によるアクセスコントロールがもたらす整合性の保証。１つのデータに対して複数のトランザクションが処理を行わなければならないような条件下においては「それぞれのトランザクションは隔離された状態でデータの処理を行なわなければならず、結果としての各トランザクション個別の更新内容が、時系列で反映されていなければならない」といった事を保障する性質。

持続性（Durability）

トランザクションによって処理されるデータは、一連の処理が全て完了し確定するまでは実際のデータに変更は加えられない。別の言い方をすると「トランザクション完了後に障害等が発生したとしても、データ自体が損なわれる事はない」といった事を保障する性質で、データベースシステムにおけるジャーナリングの機能面に関する基本構造といえる。尚、今回紹介しているファイルシステムにおけるジャーナリングでは、この持続性（Durability）が完全に保障されている訳ではない。

以上のような性質は、それぞれの頭文字から「ACID特性」と呼ばれており、これらトランザクションの持ち得る特性を有効活用し、ファイルシステムにおける不整合等を事前に防止するための機能が、ジャーナリングファイルシステムの大きな特徴の一つといえます。

●ジャーナリングファイルシステムの基本的な仕組みと、トラブル発生時における対応

では、ジャーナリングファイルシステムは、実際にどのような仕組みでシステムの可用性向上に貢献しているのでしょうか。基本的なプロセスを以下に示してみる事とします。

トランザクションによる処理の結果、或いはディレクトリエントリ（注２）に追加すべくした情報等を一時的にメインメモリに退避
トランザクションによって齎される、ファイルシステムに対する継続的な変更記録をジャーナルとして専用の領域に記録
「1.」の過程でメインメモリに退避されていた内容をHDD上の対応するブロックに転記（この際の書込処理は、データベース上では「コミット」、ファイルシステム上では「フラッシュ」と各々称されている）
書き込み終了後、ジャーナルを破棄（ジャーナル領域の解放）

以上のように、ジャーナリングファイルシステムではディスク上における任意の処理に対して、４つの段階を経て完了とする事により、ファイルシステムにおける整合性の確保を実現しています。そして「2.」「4.」の過程で作成される「ジャーナルファイル」の存在がジャーナリングの語源にもなっており、Mac OS Xの場合、このジャーナルファイル自体はディスク上において物理的に存在する１つのファイルとして生成（注３）されますが、不可視属性として定義されるのでFinder上からその存在を確認する事はできません。

続いて、ディスク上における実際のトラブル発生時に、ジャーナリングがどのような対応をもってファイルシステムの保護に努めているのかを紹介します。この場合のトラブルとは、不慮の要因による電源断、及び強制再起動等、適切な終了処理を行わずしてシステムが停止に至った場合を仮定します。

まずは「1.」～「2.」に至るまでの過程でトラブルが発生した場合を想定してみます。この際「2.」の過程で作成されるジャーナル（開始log）が不完全であった場合には、該当トランザクション自体が完全に無効とされ（全く無かったものと見なされる）ファイルシステム自体には変更が加えられません。つまりトランザクション発生以前の時点にロールバックする事になります。

次に最も不安な要素を含む「2.」のジャーナル記録直後から「3.」のHDDへの転記を経て、完了からジャーナル領域の解放に至るまで間にトラブルが発生した場合。つまりジャーナルのみが存在し、該当ファイルが存在しない場合には、システムの復旧（再起動）時に改めてジャーナルを再読み込みし、ディスクに対する該当トランザクションの再書き込み（リライト、ジャーナルに記録されていたトランザクション内容の再実行）が実行される事となります（ロールフォワード）。そしてこのような構造によって、先に著したトランザクションにおける原子性（Atomicity）の永続的な反映が実現されており、ジャーナリングにおけるこれら一連の動作は、ファイルシステムの整合性保護に加えて、その先にある本来の目的「可用性（Availability）の向上」にも貢献している事となります。

※ジャーナリングファイルシステムによって保護されているのはファイルシステムにおける整合性であり、強いてはファイル自体の消失を防ぐといったところにあります。つまり一貫性の保証はデータレベルではなく、ファイルシステムレベルで行われているものであり、ロールバックを伴うような処置が発生した場合には、保存した筈の編集結果が破棄されているといった事も有り得ます（「2.」の過程で記録される筈のジャーナルが不完全な状態になってしまった場合、「1.」の過程でメインメモリに保持されている変更結果は破棄されてしまう）。このような側面からも、いつの時代においてもバックアップの重要性は不変であるとの認識が重要かと考えます。

●ジャーナリングがもたらす真の恩恵、可用性（Availability）への貢献

続いて、ジャーナリングがどのような形で可用性の向上に貢献しているのかを考えてみましょう。まずジャーナリングが無効となっているファイルシステムにおいて、適切な終了処理を行わずしてシステムが停止に至った場合、Mac OS Xは次回起動時に通常比て数倍～数十倍の起動時間を要する事となります（ボリューム容量に比例して起動時間も長くなります）。これは、このような事態が発生した際には、起動プロセスの過程で「fsck」（注４）と呼ばれるシングルユーザモードにて提供されるUNIX由来のメンテナンスコマンドが実行され、ファイルシステムにおける整合性の検証、或いは修復等を行うために要する時間であり、旧Mac OS時代からのユーザの方は「コントロールパネル」>「一般設定」>「コンピュータが不適切に終了したら警告する」の項目がオンになっている場合を思い出して頂けると分り易いかと思います。この場合には、起動プロセスの途中（機能拡張の読込み、アイコンパレードが終了した直後）にディスクの検証を促す警告が現れ、そのまま実行すると「Disk First Aid」が起動し、ファイルシステムの検証と修復を行っていたかと思いますが、結果的にこれらfsckやDisk First Aidによる検証は、本来であれば（適切な終了処理が行われていれば）必要としないプロセスとして、起動処理に追加されていた事になります。そしてこのようなコンピュータにおけるダウンタイムは、一般的なクライアントコンピュータであれば、さしたる影響を及ぼす事も少ないかと思われますが、データベースを始めとする種々のエンタープライズ用途のサーバ上においては、直接、間接を問わずして様々な影響を広範囲に渡って及ぼしてしまう危険性が充分に考えられる事でしょう。そしてこれらの問題に対する幾つかの答えとして、ジャーナリングが持ち得るファイルシステムにおける整合性の維持と、それに伴う不正終了後のファイルシステム検証プロセスの省略、或いはジャーナルを参照する事による検証時間の短縮（ジャーナル領域のみの確認による、リカバリ時における検証範囲の限定）といった事等が挙げられ、これらのメリットは、昨今に見られるようなエンタープライズ用途の大容量ストレージにおいては、より大きな効果をもたらすに至っています。そしてこのような性質からジャーナリングにおける真の存在価値を、ファイルシステムの整合性保護から繋がる、サーバシステムや接続されているストレージデバイスに対する可用性、及び耐障害性の向上に見出す事ができるのでしょう。

●Mac OS Xにおけるジャーナリングファイルシステムのサポート状況

このように一定条件下におけるファイルシステムの信頼性と、システム全体の可用性の向上に多大な貢献を果たしているジャーナリングファイルシステムですが、Mac OS X（Server）において利用可能となったのはMac OS X 10.2.2に至るアップデート時が最初となっています。当時、Mac OS X Serverにおいてはディスクユーティリティ（/Aplication/Utilities/Disk Utility.app）を利用する事によるGUIのインターフェイスを用いた適用可否の制御が可能となっていましたが、より普及率の高いクライアント版においては、対応当初は隠し機能としての扱いとなっており、ターミナル（/Aplication/Utilities/Terminal.app）を介したコマンドラインによる制御のみの対応となっていました。尚、ターミナルを用いて、起動ボリューム全体に対してジャーナリングを適用にする際には、ターミナル上にて以下のコマンドを実行します。

sudo diskutil enablejournal /

一方、ジャーナリングを無効にする場合には、

sudo diskutil disablejournal /

※いずれも要管理者権限。任意のボリュームや、ディレクトリ単位での適用も可能

となっており、仮に任意のボリュームに対して適用されているファイルシステムが不明な場合で、Mac OS X ボリュームから起動して調べる事ができない状況下においては、何れかのコマンドラインユーティリティを利用して以下のコマンドを実行する事により確認可能となっています。

diskutil info /

ターミナル上にて「diskutil info」を実行した状態
↑「diskutil info /」の実行例。ここでは便宜上ターミナルを利用している

コマンドラインユーティリティから返されたリスト中のFile System項目が「Journaled HFS+」と表示されたら、そのボリュームがジャーナリング適用済みである事が確認できます。尚、Mac OS X 10.3 Panther以降では、クライアント版においても、

「ボリュームフォーマット」のオプションにおけるジャーナリング適用の可否
稼働中のボリュームに対するジャーナル記録の開始／停止

等が、ディスクユーティリティによって提供されるGUIのインターフェイスにて制御可能となっており（ジャーナル記録を停止させる場合は、ディスクユーティリティにて「ファイル」メニューを「option+クリック」すると、「ジャーナル記録停止」項目が出現する）、HFS Plusが適用されているボリューム同士であれば、ジャーナリングの有無によって互換性が失われるといった事はありません。そして現在のディスクユーティリティにおけるデフォルト設定や、Macintoshコンピュータの出荷時におけるファイルシステムの適用状況等を見ても、既にジャーナリングが標準機能として認知されている事は疑いようの無い事実であり、これは偏にディスク性能の向上やジャーナリング自体の機能改善（ジャーナル更新と実データ書き込みを非同期にて行う事により、一定量まとまった状態での効率良いディスクアクセスを実現）によるディスクパフォーマンス低下の回避、或いは近年における種々のOSの電源管理ポリシーや、それに伴うクライアント使用状況（頻繁にシャットダウンを行わずして、極力スリープにて対処する）等といった、Mac OS X自体に求められているエンタープライズ性能の実現等に起因しているものと思われます。

そして前述のように、ボリューム同士の互換性においてはジャーナリングの有無に影響される事はありませんが、一部のサードパーティ製メンテナンスアプリケーションを使用するにあたっては対応状況の確認が重要となってきます。特にMac OS市場において圧倒的な実績と信頼性を誇るAlsoftによる「DiskWarrior」に関しては、オペレーティングシステムのバージョンとジャーナリングの有無を考慮して適切なバージョンを選択する必要があり、ジャーナリングが適用されたボリュームに対して旧バージョンである「DiskWarrior 2.x」を使用すると例外無くクラッシュしますので要注意が必要です（私の経験上、100%ファイルシステムが破壊されます）。基本的には（DiskWarriorに限った事ではありませんが）常にメーカによる対応状況を意識しつつ、最新バージョンの使用を心掛ける事が肝要かと思われます（注５）。尚、先程も紹介したfsckをジャーナリングボリュームに対して実行した場合、以下のような問題の無いエラーが表示される場合がありますが、ファイルシステムにおける実際の損傷を報告している訳ではないで、基本的には無視して頂いて構いません。fsckにオプションとして「-fy」スイッチを付加して、そのまま実行すれば検証と修復が可能となります。

※fsckが報告する幾つかのエラーメッセージのうち、ジャーナリングを適用しているボリュームに関しては、以下のエラーメッセージは無視して構わない

Volume bitmap needs minor repair
Invalid volume free block count
Volume header needs minor repair
can't locate IOPlatformMonitor
Incorrect block count for file

ここまで紹介してきたように、ファイルシステムにおける高可用性と高信頼性の実現に多大な貢献を果たしているジャーナリングファイルシステムは、エンタープライズクラスのシステムのみならず、通常のクライアントコンピュータにおいても必要不可欠な機能となりつつあります。その存在自体はユーザの目に見えないところでの稼働がメインとなるだけに、機能の存在にすら気づかれない「縁の下の力持ち」的な活動が多いのが実情ですが、普段何気なく安定して使えているシステムの裏側には、ジャーナリングがもたらす福音が少なからず存在している事を心の片隅にでもおいて頂ければ、このコラムを造った事に対する意義が感じられるというものです。

次回はZeroConfネットワーク「Bonjour」を紹介する予定です。

●本文訳注

（注１）RASIS

コンピュータシステムの信頼性評価の指標とされる５つの項目を定義したもの。「Reliability（信頼性）」「Availability（可用性）」「Serviceability（保守性）」「Integrity（保全性）」「Security（機密性）」の５項目から成り立っている。

（注２）ディレクトリエントリ

ファイルやフォルダ等、ディスク上のリソースに関する属性情報（エントリ名、拡張子、サイズ、更新年月日（時刻）、ファイルの開始クラスタ等）が記録されている管理領域で、ボリューム上のツリー構造を構築する上で重要な役割を果たしている。MS-DOSにおける「dir」やUNIXにおける「ls」等、ディレクトリやファイル情報をリスト表示させるためのコマンドは、このディレクトリエントリを参照している。尚、ルートディレクトリ直下に保存されている種々のリソースと、サブディレクトリ以下に保存されているそれとでは、それぞれを管理しているディレクトリエントリ自体の格納場所が異なる。

（注３）ディスク上において物理的に存在する１つのファイルとして生成

Mac OS XのHFS Plusや、Linuxカーネル2.4以降からサポートされている「ext3（third extended file system）」等におけるジャーナリングでは、ジャーナルファイルは物理的に存在する１つのファイルとして生成されるが、一方ではジャーナル専用の領域を確保し、そこにジャーナルファイルを記録しているファイルシステムも存在する。尚、ext3ではファイルシステムの整合性の維持と共に、データレベルでの一貫性も保障されている。

（注４）fsck

filesystem consistency check and interactive repairの略。ファイルシステムにおける整合性の検証、及び修復を行うためのコマンドラインユーティリティで、通常シングルユーザモードからコマンドを用いて利用する事となる。尚、ディスクユーティリティの機能の一部でもある「First Aid」は、fsckの機能をGUIレベルにて提供したものであり、起動ディスクに対する修復をサポートしていないFirst Aidに対し（検証は可能）、利用環境の如何によって修復まで可能としているのは、fsckが持ち得る大きなアドバンテージといえる。尚、Appleによる公式な文書の中には「Mac OS X 10.3 Panther、またはそれ以降のバージョンで、Mac OS X拡張（ジャーナリング）フォーマットのボリュームを使用する場合は、fsckを使用する必要はないでしょう」といった記述が見られる。

（注５）最新バージョンの使用を心掛ける事が肝要

OSのバージョンではないので要注意。10.2.xでもジャーナリングが有効になっているボリュームに対する、DiskWarrior 2.xの使用は厳禁であり、逆にジャーナリングを無効にしていれば10.3.xでも利用可能となる。尚、10.4.xに関しては対応バージョン（3.0.3以降）が必須となる。

御意見、御感想はこちらまで
 Topページへ

Created Date : 06/05/01
Modified Date :