デベロッパー:Linux How-To 2005年10月07日 01:02 更新
fsckはジャーナリングで不要にはならない

 いままで説明してきたように、ext3ファイルシステムはジャーナリングが搭載され、不正なシャットダウン後にfsckコマンドを実行する必要がなくなったわけだが、ジャーナリング機能があればfsckコマンドは不要というわけにはならない。

 なぜならばext3ファイルシステムのジャーナリング機能は、メタデータや実際のデータがディスクに確実に記録することを保証するだけであり、ディスク上のトラブルやアプリケーションの不具合などによるメタデータの破壊には対応しないからだ。

不正なシャットダウン後の処理

 ext3ファイルシステムを使っている場合、正しくシャットダウンせず、不正なシャットダウンが起こったことが分かると、再起動時において、自動的にジャーナリングとの照合が行われる。そしてジャーナリングの状態と不整合があれば、それを直ちに修復する。この過程は起動時に画面に表示されるが、あとでdmesgコマンドを実行すると確認できる。

Journalled Block Device driver loaded
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
EXT3-fs: sd(8,2): orphan cleanup on readonly fs
ext3_orphan_cleanup: deleting unreferenced inode 265599
ext3_orphan_cleanup: deleting unreferenced inode 103363
ext3_orphan_cleanup: deleting unreferenced inode 103377
EXT3-fs: sd(8,2): 3 orphan inodes deleted
EXT3-fs: recovery complete.
scsi0: Tagged Queuing now active for Target 0
EXT3-fs: mounted filesystem with ordered data mode.

 上記の例では、iノードに不正があったため、それを修復したということを示している。ext3では、fsckコマンドを強制実行される場合と違い、ジャーナリングとの不整合がある箇所だけを調べるため、その修復にかかる時間はごくわずかである。

それでもfsckコマンドは必要

 しかし逆にいえば、ext3ファイルシステムでは、不正なシャットダウンがあったとしても、ジャーナリングとの不整合に関係ない箇所は調査の対象にならない。よって、場合によってはディスクが壊れっぱなしになる恐れがある。

 ソフトウェア的な問題やディスク以外の問題で不正なシャットダウンが生じた場合には問題となることはないが、もしかすると不正なシャットダウンの原因はディスクそのものにあるかも知れない。ディスクそのものの原因の場所がジャーナリングの不整合の範囲内にあれば、再起動時に調査されるわけだが、そうではない別の場所の不具合の場合には、調査の対象とはならない。よって壊れたままディスクを使い続けてしまう可能性を秘めている。

 そういった理由から、ジャーナリングファイルシステムは、再起動時のfsckコマンドの実行にかかる時間を短縮するという効果はあるが、ディスク上の全不具合を見るわけではないため、ジャーナリングファイルシステムがあればfsckコマンドは不要であるということにはならない。やはり従来と同様に、定期的な間隔でfsckコマンドを実行することが望ましい。

 Red Hat Linuxでは、ルートディレクトリにforcefsckというファイルを置いて再起動すると、再起動時に強制的にfsckコマンドを実行するので、適時時間があるときに、きちんとfsckコマンドを実行して、ディスク全体をチェックをすることを推奨する。

 なおmke2fsコマンドでext3ファイルシステムを作成した場合、35回マウントされるかマウント後に180日間経過した後、再マウントしようとした場合には、再起動時に強制的にfsckコマンドが実行されるようになっている。

 ただし対象となるのは、/etc/fstabファイルに書かれているものだけであり、また/etc/fstabの第6番目のフィールドであるfsckがチェックするマウント回数に0が指定されている場合には、この限りではない。

One Point!Red Hat Linux 7.2をインストールしたとき、インストーラが作成したext3ファイルシステムにおいては、マウント回数、マウント期間ともに無効になっており、何回マウントしても、またマウントしてから何日経過しても、再起動時にfsckが自動的に実行されるようなことはない。

 この設定は、dumpe2fsコマンドを実行すると調べることができる。表示されているMaximum mount countがマウント回数の間隔、Check intervalが時間間隔である。

# dumpe2fs ブロックデバイス名
dumpe2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09
Filesystem volume name: >none<
Last mounted on: >not available<
Filesystem UUID: f5b5c0fd-e13a-4a40-b122-6d898debd07a
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype sparse_super
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
・・・中略・・・ Last mount time: Thu Jan 1 09:00:00 1970
Last write time: Mon Dec 17 07:02:22 2001
Mount count: 0
Maximum mount count: 35
Last checked: Mon Dec 17 07:02:21 2001
Check interval: 15552000 (6 months)
Next check after: Sat Jun 15 07:02:21 2002
・・・後略・・・

 これを解除するには、tune2fsコマンドを次のように実行する。

# tune2fs -c0 -i0 ブロックデバイス名

 これにより、マウント回数が0回、時間間隔がなしに設定され、再起動時のfsckコマンドの実行が一切なくなる。

 ただし先に説明したように、ジャーナリングファイルシステムはfsckコマンドの実行が不要という意味ではないから、このような設定にしたとしても、適当な間隔で、手動でfsckコマンドを実行することを推奨する。

ext3ファイルシステムを過信してはならない

 いままで説明してきたように、ext3ファイルシステムは、基本的に不正なシャットダウン時に起こる再起動のfsckコマンドの実行の遅さをカバーするものでしかない。

 すなわちext3ファイルシステムを使っても、ファイルは壊れるときには壊れるので、やはりバックアップは欠かせないし、適時fsckコマンドの実行も欠かすことはできない。

 ext3ファイルシステムはjournalモードやorderedモードで動作させれば、ディレクトリが読めなくなったりディスク全体が読めなくなってしまうといった致命的なエラーを防ぐことはできるが、依然として、完璧にデータを保護するわけではない。

 ext3ファイルシステムは、不正なシャットダウン後の再起動時の高速化を提供するものであると考え、それ以上の過度な期待はしないほうがよいだろう。

PREV 3/3 space