ファイルシステムの技術：ファイルシステムの基礎知識（2）（1/2 ページ）

ハードディスク、あるいはブロックストレージと呼ばれるものにファイルシステムを適用することで、データの保存や整理、利用が可能になる。ではファイルシステムとは何か？本連載では、知っているようで分からないことの多い、このファイルシステムについて基礎から説明する。

[星野隆義，シマンテック]

はじめに

　第1回では「ファイルシステムとは何か」について述べたうえで、その知識が普段の業務に役立つ例としてパフォーマンス劣化と情報漏洩の防止を挙げ、それぞれについて掘り下げてみた。これにより、大量のファイルを保存したまま整理を怠っていると徐々にPCの動きが遅くなってくる理由や、PCを廃棄する場合にハードディスクの物理的な破壊を強いられる理由が理解いただけたかと思う。

　第2回では、ファイルシステムの技術について、さらに掘り下げてみたい。今回のテーマは『障害』と『パフォーマンス』の2つである。最近のファイルシステムは、10年以上前と比べると非常に堅牢でトラブルが発生しにくくなっているが、その理由について触れてみたい。次に、ファイルシステムのパフォーマンスに大きな影響を与える内部の仕組みについて説明したうえで、単純な設定を行うだけで簡単にファイルシステムのパフォーマンスの劣化を防止する方法を紹介する。

ファイルシステムの障害とジャーナル機能

　ファイルシステムの障害について説明する前に、前回説明したファイルシステムの仕組みについて思い出してほしい（図1）。ファイルシステムを本に例えて説明したが、第2回でも同じ例えを使って説明したい。ただし、一度完成されると、その後に内容が変更されない実際の本ではなく、頻繁に内容が追加・削除・変更される特殊な本を想像してほしい。

図1 ファイルシステムを本に例える

　ファイルシステムの障害の多くは、本の例えでいえば「目次」と「章やページ」の情報の不整合が原因で発生する。つまり「カレーの作り方」を調べたくて料理の本の目次を開き「カレーの作り方：68ページ」という記述があったので68ページを開いたところ、全く別の料理のレシピが書いてあった、という状況である。このような場合「この料理本は乱丁本である」と判断して、使用を控えるのが一般的だろう。

　では、実際のファイルシステムの世界に話を戻そう。ファイルシステムの場合は、「ハードディスクの先頭からXXバイト目からYYバイト目の間に、AAAという名前のファイルが格納されている」という情報と、「AAAという名前のファイルが存在するか否か、存在するとしたらそのデータが格納されているハードディスク上の位置」という情報の間に矛盾がある状況が「ファイルシステムの障害」ということになる。

　このような状況が発生するのは、ファイルシステムを更新する際に、インデックス部分と実データ部分を別々のタイミングで書き換えていることに起因する。AAAという名前の10メガバイトのファイルを作成する場合を例に、もう少し具体的に説明しよう。話を簡単にするために、インデックスの作成と、データ部分のディスクへの書き込みに限定して説明するが、実際はそれ以外のさまざまな処理もファイルシステムの内部で行われている。

　「10メガバイトの既存エクセルファイルをコピーして、あるフォルダの配下に、AAAという名前の10メガバイトの新規ファイルとして作成せよ」という命令を、アプリケーションからファイルシステムが受け取ったとする。ファイルシステムは、ハードディスク上の空き領域をチェックし、どのあたりにAAAという名前のファイルを配置するか決定する。そして、「どのあたりに配置されているか」という情報をハードディスクのインデックス領域に記録する。ほとんどの場合、その時点で、アプリケーションに対して「処理が完了しました」という連絡をしてしまう。その後で、メモリ上にあるデータを、ハードディスク上の然るべき場所に書き込んでいく。このような処理を行う理由は、アプリケーションに対する待ち時間を短縮し、システム全体の処理スピードを上げるためである。専門用語では、このような処理を「非同期I/O」という。システムの処理スピードを上げるための非同期I/Oであるが、OSの異常停止等のトラブルが発生すると、ファイルシステムの障害の原因となる。その理由は、ファイルシステムを更新する場合の処理を考えれば、おおよそ予測が付くだろう。AAAという名前のファイルを作成する過程で、インデックスに関連する処理のみが完了し、AAAという名前のファイルの実データをハードディスクに書き込む前、もしくはその過程で、OSの異常停止等のトラブルが発生した場合、インデックス部分と実データ部分に矛盾が発生する。

　ファイルシステムには、このような矛盾が存在するか否かを認識する機能と、矛盾が存在した場合にその矛盾を取り除く機能が用意されている。まず、「矛盾が存在するか否かを認識する機能」について説明する。ファイルシステムには「更新に関わる処理が全て完了したかどうかのフラグ」があり、このフラグはハードディスク上に書き込まれている。つまり、あるファイルのインデックスに関連する処理は完了したが、そのファイルの実データをハードディスクに書き込む処理は未完了という状態では、フラグは「処理未完了」になっている。この状態でOSの異常停止等のトラブルが発生すると、OSの再起動後に「ファイルシステムに矛盾がある」と認識する。

　次に、「矛盾を取り除く機能」について説明する。やり方は単純である。ファイルシステムの中に存在するインデックスと実データを全て対比して、矛盾がある部分を調べる。そして矛盾があった場合は、それを取り除く。つまり、実態データのハードディスクへの書き込みが完了していない部分を見つけ、それと対応するインデックスを削除してしまうのである。この作業は、ファイルシステムの中にあるファイルの数が多くなればなる程時間がかかる。分厚い百科事典の目次と各ページ内容に矛盾がないか1ページ1ページめくって確認するのに気の遠くなるような時間がかかるのと同じである。下記は、Windows OSの異常終了後に、ファイルシステムに異常の可能性が見つかり、そのチェックを行っている画面である。1990年代初頭にWindowsを多用していた方は、見たくない画面かもしれない。

図2　Windowsにおけるファイルシステムの不整合発生例。Cドライブの不整合の可能性が発見され、チェックディスクが実行されている

　ひとたびファイルシステムの矛盾の可能性が発生すると、ファイルシステム全体の整合性の確認および矛盾情報の削除が完了するまで、ファイルシステムは使用不可能となる。今から10年以上前は、数時間から数日を要することも稀ではなかった。この使用不可能な時間をいかに短くできるかがシステムの堅牢性に大きく関係している。

　この、使用不可能な時間を短くするための手法が「ジャーナル機能」である。UNIXでは1990年代初頭に、LinuxやWindowsではそれよりも数年遅れて一般的になった手法である。ジャーナル機能を持ったファイルシステムの最大の特徴は「更新に関わる処理が完了したかどうかのフラグ」を、個々のファイル毎に持っていることであり、このフラグの集まりを「ジャーナル」と呼んでいる。Windows 95に搭載されたFAT32やバージョン2.6以前のSolarisに搭載されたUFSに代表されるジャーナル機能のないファイルシステムの場合、ファイルシステムの矛盾の可能性が指摘されると、ファイルシステムの中に存在するインデックスと実データを全て対比する必要があった。一方、Windows NTに搭載されたNTFSやベリタスファイルシステム（現在はシマンテックのVeritas Storage Foundationに含まれる）に代表されるジャーナル機能付きのファイルシステムの場合、ファイル毎に「更新に関わる処理が完了したかどうかのフラグ」を持っているので、フラグが「処理未完了」になっているファイルだけをチェックし、必要なリカバリ処置を行えばよい。これにより、ファイルシステム全体の整合性の確認及び矛盾情報の削除に要する時間は劇的に短縮された。

　しかし、ジャーナル機能への過信は禁物である。非同期I/Oを行っている以上、ファイルの更新処理中にOSの異常停止等のトラブルが発生した場合、更新途中だったファイルの情報が消えてしまうことは覚悟しなければならない。もう少し具体的に言うと、「アプリケーションは書き込み完了の通知を受け取っているが、OSの異常終了発生時点でハードディスクへ書き込みが未完了であったファイル」が消えてしまうのだ。ジャーナル機能の価値は「ファイルシステムが使えない時間を短くする」点であることを忘れてはならない。

　OSの異常停止等のトラブルが発生した場合に、前述のような問題が発生するのを防ぎたければ、非同期I/Oを止めるしかない。こうすれば、ハードディスクへ書き込み完了後にアプリケーションが書き込み完了の通知を受け取るので、問題は発生しない。しかし、ファイルシステムのパフォーマンスが大きく低下するだけでなく、非同期I/Oを行わない設定をするには高度な知識と多くの手間を要する。パフォーマンスを犠牲にしたとしてもデータの消失が許されないシステム要件であれば仕方がないが、通常は現実的とは言えないだろう。これが、ファイルシステムの限界であることを認識してほしい。一度に大量のファイルを更新もしくは作成している途中に、OSの異常停止等のトラブルが発生した場合、更新途中だったファイルの情報が一部もしくは全部失われてしまう事は覚悟しなければならず、その悪影響を小さくしようと思えば、ファイルの更新もしくは作成を一度に大量に行うのではなく、少量を頻繁に行うようにすべきである。