UFS ファイルシステムの整合性チェック (手順)
この章では、UFS ファイルシステムの整合性チェックに関する概要と手順について説明します。
この章で説明する手順は次のとおりです。
この章の内容は以下のとおりです。
fsck のエラーメッセージについては、『Solaris のシステム管理 (上級編)』の「UFS ファイルシステムの不整合解決 (手順)」を参照してください。
この章で参照される UFS ファイルシステム構造の内容については、第 43 章「UFS ファイルシステム (参照情報)」を参照してください。
ファイルシステムの整合性
UFS ファイルシステムは、一連の内部テーブルを基にして使用済み i ノード、使用可能ブロックを特定します。これらの内部テーブルがディスク上のデータと正しく同期していないと、整合性が失われ、ファイルシステムの修復が必要になります。
次のような原因でオペレーティングシステムが異常終了すると、ファイルシステムの整合性が失われることがあります。
電源障害
不注意によるシステム電源の切断
正しいシャットダウン手順以外の方法によるシステム電源の切断
カーネル内のソフトウェアエラー
ファイルシステムの整合性が失われることは重大ですが、頻繁に起きるものではありません。システムをブートすると、ファイルシステムの整合性チェックが (fsck コマンドを使用して) 自動的に実行されます。ほとんどの場合は、このファイルシステムのチェックによって問題が修復されます。
fsck コマンドは、ファイルシステム上に配置されているが参照不可能なファイルとディレクトリを lost+found ディレクトリに入れます。参照不可能なファイルとディレクトリの名前として i ノード番号が割り当てられます。lost+found ディレクトリが存在しない場合は、fsck コマンドによって作成されます。lost+found ディレクトリ内の領域が足りない場合は、fsck コマンドによってそのサイズが拡張されます。
i ノードについては、i ノードを参照してください。
ファイルシステムの状態はどのように記録されるか
fsck コマンドは、スーパーブロックに格納された状態フラグを使用して、ファイルシステムの状態を記録します。また、このフラグを使用して、ファイルシステムの整合性をチェックする必要があるか判断します。このフラグは、ブート時に /sbin/rcS スクリプトによって使用されるか、fsck -m コマンドによって使用されます。fsck -m コマンドの結果を無視する場合は、状態フラグの設定に関係なく、すべてのファイルシステムをチェックできます。
スーパーブロックについては、スーパーブロックを参照してください。
表 42-1 に状態フラグの値とその説明を示します。
表 42-1 ファイルシステムの状態フラグの値
状態フラグの値 | 説明 |
|---|---|
FSACTIVE | ファイルシステムのマウント後、変更されると、状態フラグが FSACTIVE に設定される。ファイルシステムの整合性が失われている可能性がある。変更後のメタデータがディスクに書き込まれるまでは、ファイルシステムに FSACTIVE マークが付けられる。ファイルシステムが正常にマウント解除されると、状態フラグは FSCLEAN に設定される。FSACTIVE フラグが設定されたファイルシステムは、整合性が失われている可能性があるので、fsck コマンドでチェックしなければならない。 |
FSBAD | ルート (/) ファイルシステムが、FSCLEAN でも FSSTABLE でもない状態のときにマウントされると、状態フラグが FSBAD に設定される。カーネルが、このファイルシステムの状態を FSCLEAN または FSSTABLE に変更することはない。ブートの処理の一部として、ルート (/) ファイルシステムに FSBAD フラグが設定された場合、ルートファイルシステムは読み取り専用としてマウントされる。ルートの raw デバイスに対して fsck コマンドを実行できる。その後で、ルート(/)ファイルシステムを読み取り/書き込み用にマウントし直す。 |
FSCLEAN | ファイルシステムが正しくマウント解除された場合は、状態フラグが FSCLEAN に設定される。FSCLEAN 状態フラグが設定されているファイルシステムは、システムのブート時にチェックされない。 |
FSLOG | UFS ロギングを有効にしてファイルシステムがマウントされた場合は、状態フラグが FSLOG に設定される。システムのブート時、状態フラグが FSLOG のファイルシステムはチェックされない。 |
FSSTABLE | ファイルシステムはマウントされている (またはされた) が、前回のチェックポイント (sync または fsflush) 以後に変更がなかった。チェックポイントは、通常は 30 秒ごとに発生する。たとえば、カーネルはファイルシステムがアイドル状態かどうかを定期的にチェックし、アイドル状態であれば、スーパーブロック内の情報をディスクにフラッシュさせて FSSTABLE マークを設定する。システムがクラッシュした場合、ファイルシステムの構造は正しいが、少量のデータが失われている可能性がある。FSSTABLE マークが付いたファイルシステムは、マウント前のチェックをスキップできる。ファイルシステムの状態が FSCLEAN 、FSSTABLE 、または FSLOG のいずれでもない場合は、mount コマンドによってファイルシステムを読み取り/書き込み用にマウントできない。 |
表 42-2 に、fsck コマンドを使用して、初期状態に基づいて状態フラグを変更する方法を示します。
表 42-2 fsck による状態フラグの変更内容
初期状態 : fsck の実行前 | fsck の実行後 |
| |
|---|---|---|---|
エラーなし | すべてのエラーを修正済み |
エラーが未修正 | |
不明 | FSSTABLE | FSSTABLE | 不明 |
FSACTIVE | FSSTABLE | FSSTABLE | FSACTIVE |
FSSTABLE | FSSTABLE | FSSTABLE | FSACTIVE |
FSCLEAN | FSCLEAN | FSSTABLE | FSACTIVE |
FSBAD | FSSTABLE | FSSTABLE | FSBAD |
FSLOG | FSLOG | FSLOG | FSLOG |
fsck コマンドでチェックして修復される内容
この節では、ファイルシステムの通常の処理中に発生する問題、原因、fsck コマンド (チェックおよび修復ユーティリティ) で検出される問題、およびそれらの修正方法について説明します。
不整合が発生する原因
就業日には毎日多数のファイルが作成、変更、または削除されます。ファイルが変更されるたびに、オペレーティングシステムは一連のファイルシステムの更新処理を実行します。これらの更新処理がディスクに確実に書き込まれると、ファイルシステムの整合性が保たれます。
ユーザープログラムが書き込みなどの、ファイルシステムを変更する処理を実行すると、書き込まれるデータはまずカーネルのインコアバッファーにコピーされます。一般に、ディスクの更新は非同期に処理されます。このため、ユーザープロセスは、書き込みシステムコールが値を返した後すぐに処理を続けることができますが、実際のデータの書き込みは、ずいぶん後に実行されることもあります。したがって、ディスク上にあるファイルシステムは、インコア情報で表されるファイルシステムの状態から常に遅延することになります。
別の目的にバッファーが必要になったり、カーネルが fsflush デーモンを自動的に (30 秒間隔で) 実行すると、インコア情報を反映するようにディスク情報が更新されます。システムがインコア情報を書き込まずに停止すると、ディスク上のファイルシステムの整合性がなくなります。
ファイルシステムの整合性は、さまざまな原因で失われることがあります。最も一般的な原因は、オペレータのエラーとハードウェア障害です。
システムを正しくシャットダウンしなかったり、マウントされているファイルシステムが正しくオフラインにされないと、「クリーンでないシャットダウン」が原因で問題が発生することがあります。クリーンでないシャットダウンを防ぐには、システムをシャットダウンしたり、ディスクをドライブから物理的に取り出したり、ディスクをオフライン状態にする前に、ファイルシステムの現在の状態をディスクに書き込まなければなりません (つまり、同期させなければなりません)。
また、ハードウェアの欠陥が原因で整合性が失われることもあります。ディスクドライブ上ではいつでもブロックが損傷する可能性があり、ディスクコントローラが正常に機能しなくなる可能性があります。