| デベロッパー：Linux How-To | 2005年10月07日 01:02 更新 |
|
 |
なぜファイルが壊れるのか |
ジャーナリングに対応したファイルシステムを使うにあたり、まず、なぜファイルシステム上のデータが壊れるのかという点について簡単に説明しておこう。
ファイルを壊した経験がある人ならわかるが、ファイルが壊れるのは、システムが不正に終了したような場合や、ファイルのアクセス中に正しい手順（shutdownコマンドの実行など）をとらずに電源を落としてしまった場合などである。
メタデータシステムが突如停止したり、システムの電源をいきなり落とした場合、そのとき書き込んでいたファイルの一部が失われるというのならば話は簡単なのだが、そういうわけではない。
ファイルシステムの構造にもよるが、一般にファイルは、ハードディスク上にブロックごとに分割されて格納される。
Linuxがデフォルトで利用しているext2ファイルシステムの場合、Fig.1のような構成をとる。
Fig.1■ext2ファイルシステムの構成
※Filesystems-HOWTOより抜粋
ext2ファイルシステムでは、ファイルの実際の中身は断片化されて、「データブロック」の部分に格納される。データブロックの部分には「iノード」と呼ばれる番号が付けられて管理される。
データブロックの大きさは、mke2fsコマンドを使って新しくファイルシステムを作ったときのブロックサイズのオプションにも依存し、1024バイト、2048バイト、4096バイトのいずれかが使われる。すなわちファイルは、ファイルシステムを作ったときのブロックサイズの大きさに分割されて格納されることになる。たとえばブロックサイズが4096バイトである場合、10000バイトのファイルは、10000バイト÷4096=3つのデータブロックに分割されて格納される。
そして、どのファイルがどの場所――すなわちどのiノードに対応する場所――に保存されているのかは、データブロックの前にある「スーパーブロック」「FS記述」「ブロックビットマップ」「iノードビットマップ」「iノード表」に格納される。これらのデータの場所を管理する場所に含まれるデータのことを「メタデータ」と呼ぶ。
メタデータが壊れると整合性が失われる
ファイルシステムにおいて、メタデータが壊れると、データの整合性が失われる。
メタデータはディスク上のデータブロックの位置や構造を示すものであるから、メタデータの一部が失われれば、データの一部へアクセスできずに消失したように見える。また、メタデータが誤って他のファイルのiノードを指すようになっていたとすれば、ファイルの一部に別のファイルの一部が表れてしまうことになる。
正しい手段でシャットダウンしなかった場合
すでに知っている人が多いと思うが、Linuxを始めとしたOSでは、ファイルを書き込む際には、直接データをディスクに書き込むのではなく、いったんキャッシュしてから書き込むことで、高速化を図っている。正しい手段でシャットダウンすれば、キャッシュ中のデータがすべてディスクに書き込まれるので問題ないが、そうでない場合には、一部のデータが書き出されない。
キャッシュされてディスクに書き込まれなかったデータがただ消失するのであれば、そのときに書き込んでいたデータが失われるだけなので問題ないが、メタデータと実際のデータ部分とで合致しないと、ディスク全体やディレクトリ全体が壊れてしまう可能性がある。
たとえば、メタデータの部分は書き換えたけれども、実際のデータ部分を書き込む前にシステムが突如終了してしまった場合には、メタデータが指すデータが不正となる。そしてまた厄介なことに、メタデータは、ディレクトリの階層を保持するものでもあるため、たとえばディレクトリの移動処理中にメタデータの書き込みが完全に行われなかった場合などには、ディレクトリの階層がループしてしまったり、別のディレクトリの下にも同じディレクトリが見えてしまうといったことになるうる。
fsckコマンド
このようにメタデータの不正は、ひとつのファイルへの影響ではなく、ファイルシステム全体への影響を及ぼす。そこでLinuxでは、起動時に正しくシャットダウンされたかどうかを確かめ、正しくシャットダウンされていない場合には、強制的にfsckコマンドを実行するようになっている。
fsckコマンドは、メタデータ部分を調査し、すべてのメタデータ部分において、不整合がないかどうかをチェックする。幸いext2ファイルシステムは、メタデータ部分がやや冗長な構成になっているため、多少の不整合であれば、自動的に修復できる（しかし壊れたデータは復活できることはなく、単純にlost+foundディレクトリ内に移動されるだけである）。
fsckコマンドの問題点は、メタデータ部分の調査に非常に時間がかかることだ。数十GBのハードディスクの場合、fsckコマンドを実行すると、数十分待たされることも珍しくない。
|
ジャーナリングファイルシステム |
fsckコマンドによるメタデータのチェックは非常に時間がかかるため、数十GBのハードディスクが当たり前である現在、それを解決すべく登場したのが、ジャーナリングファイルシステムだ。
よく整理して考えてみると、不正なシャットダウン時にfsckコマンドを実行する必要があるのは、メタデータの整合性が保たれていない可能性があるからだ。
もし不正なシャットダウン時においてもメタデータの不正がないということが保証できれば、fsckコマンドを実行する必要はない。そもそもファイルシステム全体に対するメタデータの整合性のチェックをするのは無駄であり、不正なシャットダウン時には、壊れた可能性のある部分だけをチェックすればよいのではないだろうか。
ファイルへの書き込みを記録するそこでジャーナリングに対応したファイルシステムでは、ディスクにデータを書き込む際に、直接データを書き込むのではなくて、「ジャーナリング」（または「ログ」）と呼ばれる場所に、その操作を一旦書き込んでおく。そして、その後、本当にディスクへのデータの書き込みが完了した時点で、ジャーナリングからその操作を消す。つまりジャーナリングの領域に、これから操作する手順を書いてから、実際の操作をし、操作完了後に手順を削除するようにするのだ（Fig.2）。
このようにしておけば、もし、ファイルへの書き込みの最中にシステムが不正に終了しても、再起動後にジャーナリング内に何も残っていなければ、実際にディスクへの書き込みが完了したことを意味する。
もしジャーナリング内に何か残っていれば、ディスクへの書き込みに失敗した可能性があるということがわかる。このときジャーナリング内に記載された手順内容を見れば、どのような操作をしたかがわかるから、壊れた可能性がある箇所がわかる。よってその箇所だけを調査すればよい。すなわち強制的に全メタデータを調査するfsckコマンドによるものと違い、壊れた可能性がある箇所だけを調べることで、不正なシャットダウン後のディスクチェックの時間を高速化することができるというわけだ。
 |
1/3 |  |
