第 39 章 ファイルシステムの整合性チェック

この章の内容は以下のとおりです。

• 「ファイルシステムの状態はどのように記録されるか」

• 「fsck でチェックして修復される内容」

• 「ブート時のファイルシステムチェック機能の変更」

• 「UFS ファイルシステムを対話式でチェックして修復する」

• 「不正なスーパーブロックの復元」

• 「fsck コマンドの構文とオプション」

fsck のエラーメッセージについては、『Solaris のシステム管理 (第 2 巻)』の「ファイルシステムで発生する問題の解決」を参照してください。

この章で参照される UFS ファイルシステム構造の背景情報については、第 40 章「UFS ファイルシステム (参照情報)」を参照してください。

ファイルシステムの完全性

UFS ファイルシステムは、一連の内部テーブルを基にして使用済み i ノード、使用可能ブロックを特定します。これらの内部テーブルがディスク上のデータと正しく同期していないと、整合性が失われ、ファイルシステムの修復が必要になります。

次のような原因でオペレーティングシステムが異常終了すると、ファイルシステムが損傷したり、整合性が失われたりすることがあります。

• 電源障害

• 不注意によるシステム電源の切断

• 正しいシャットダウン手順以外の方法によるシステム電源の切断

• カーネル内のソフトウェアエラー

ファイルシステムの破損は重大ですが、あまり頻繁に起きるものではありません。システムをブートすると、ファイルシステムの整合性チェックが (fsck プログラムを使用して) 自動的に実行されます。ほとんどの場合は、このファイルシステムのチェックによって問題が修復されます。

この章では、fsck プログラムでチェックされ修復される問題と fsck のオプションについて説明します。また、次の作業についても説明します。

• ブート時に実行される自動チェック機能を変更する方法

• ファイルシステムのチェックが必要かどうかを調べる方法

• UFS ファイルシステムを対話形式でチェックして修復する方法

• 不良スーパーブロックを復元する方法

• fsck で修復できない UFS ファイルシステムを修復する方法

fsck のエラーメッセージについては、『Solaris のシステム管理 (第 2 巻)』の「ファイルシステムで発生する問題の解決」を参照してください。

fsck プログラムは、ファイルシステム上に配置されているが参照不可能なファイルとディレクトリを lost+found ディレクトリに入れます。各ファイルの i ノード番号が名前として割り当てられます。lost+found ディレクトリが存在しない場合は、fsck によって作成されます。lost+found ディレクトリ内の領域が足りない場合は、そのサイズが fsck によって拡張されます。

ファイルシステムの状態はどのように記録されるか

fsck コマンドは、スーパーブロックに格納された状態フラグを使用して、ファイルシステムの状態を記録します。また、このフラグを使用して、ファイルシステムの整合性をチェックする必要があるかどうかが判断されます。このフラグはブート時には /sbin/rcS スクリプトによって使用され、コマンド行からは fsck に -m オプションを指定した場合に使用されます。fsck の -m オプションの結果を無視するのなら、状態フラグの設定に関係なく、すべてのファイルシステムをチェックできます。

表 39-1 に状態フラグを示します。

表 39-2 に、fsck コマンドを使用して、初期状態に基づいて状態フラグを変更する方法を示します。

fsck でチェックして修復される内容

この節では、ファイルシステムの通常の処理中に発生する問題、原因、fsck で検出される問題、およびそれらの修正方法について説明します。

非整合状態が発生する原因

就業日には毎日多数のファイルが作成、変更、または削除されます。ファイルが変更されるたびに、オペレーティングシステムは一連のファイルシステムの更新処理を実行します。これらの更新処理がディスクに確実に書き込まれると、ファイルシステムの整合性が保たれます。

ユーザープログラムが書き込みなどの、ファイルシステムを変更する処理を実行すると、書き込まれるデータはまずカーネルのインコアバッファーにコピーされます。一般に、ディスクの更新は非同期に処理されるので、ユーザープロセスは、書き込みシステムコールが値を返した後すぐに処理を続けることができますが、実際へのデータの書き込みは、ずいぶん後に実行されることもあります。したがって、ディスク上にあるファイルシステムは、インコア情報で表されるファイルシステムの状態から常に遅延することになります。

別の目的にバッファーが必要になったり、カーネルが fsflush デーモンを自動的に (30 秒間隔で) 実行すると、インコア情報を反映するようにディスク情報が更新されます。システムがインコア情報を書き込まずに停止すると、ディスク上のファイルシステムの整合性がなくなります。

ファイルシステムの整合性は、さまざまな原因で失われることがあります。最も一般的な原因は、オペレータのエラーとハードウェア障害です。

システムを正しくシャットダウンしなかったり、マウントされているファイルシステムが正しくオフラインにされないと、「クリーンでない停止」が原因で問題が発生することがあります。クリーンでないシャットダウンを防ぐには、CPU を停止したり、ディスクをドライブから物理的に取り出したり、ディスクをオフライン状態にする前に、ファイルシステムの現在の状態をディスクに書き込まなければなりません (つまり、同期させなければなりません)。

また、ハードウェアの欠陥が原因で整合性が失われることもあります。ディスクドライブ上ではいつでもブロックが損傷する可能性があり、ディスクコントローラが正常に機能しなくなる可能性があります。

整合性がチェックされる UFS 構成要素

この節では、UFS ファイルシステムの構成要素、つまりスーパーブロック、シリンダグループブロック、i ノード、間接ブロック、データブロックに fsck が適用する整合性チェックの種類について説明します。

スーパーブロックのチェック

スーパーブロックには集計情報が格納されており、UFS ファイルシステム内で最も破損しがちな構成要素です。ファイルシステムの i ノードやデータブロックが変更されるたびに、スーパーブロックも変更されます。CPU が停止した場合、直前のコマンドが sync コマンドでなければ、スーパーブロックはほぼ確実に破損します。

スーパーブロックの非整合性は、次の面からチェックされます。

• ファイルシステムのサイズ

• i ノード数

• 空きブロック数

• 空き i ノード数

ファイルシステムと i ノードリストのサイズのチェック

ファイルシステムのサイズは、スーパーブロックと i ノードリストに使用されるブロック数よりも大きくなければなりません。i ノード数は、ファイルシステムの最大許容数よりも小さくなければなりません。ファイルシステムのサイズとレイアウト情報は、fsck にとって最も重要な情報部分です。これらのサイズを実際にチェックする方法はありませんが、ファイルシステムの作成時に静的に判断されるので、fsck はサイズが妥当な範囲内にあるかどうかをチェックできます。ファイルシステムの他のすべてのチェックを行うには、これらのサイズが正確でなければなりません。fsck が一次スーパーブロックの静的パラメータ内に不正な情報を検出すると、オペレータに代替スーパーブロックの位置を指定するように促します。

空きブロック数のチェック

空きブロック数は、シリンダグループのブロックマップに格納されます。fsck は、空きマーク付きのすべてのブロックがファイルによって使用されていないかどうかをチェックします。すべてのブロックをチェックし終わると、fsck は空きブロック数と i ノードによって使用されるブロック数の合計がファイルシステム内の合計ブロック数に等しくなるかどうかをチェックします。ブロック割り当てマップ内に間違いがあると、fsck はブロックが割り当てられている状態のままで構築し直します。

スーパーブロック内の集計情報には、ファイルシステム内の空きブロックの合計数のカウントが入っています。fsck プログラムは、このブロック数をファイルシステム内で見つかった空きブロック数と比較します。数が一致しなければ、fsck はスーパーブロック内の空きブロック数を実際の空きブロック数で置き換えます。

空き i ノード数のチェック

スーパーブロック内の集計情報には、ファイルシステム内の空き i ノード数が入っています。fsck プログラムは、この i ノード数をファイルシステム内で見つかった空き i ノード数と比較します。数が一致しなければ、fsck はスーパーブロック内の空き i ノード数を実際の空き i ノード数で置き換えます。

i ノード数

i ノードリストは、i ノード 2 から順番にチェックされます (i ノード 0 と i ノード 1 は予約されています)。各 i ノードの非整合性は、次の面からチェックされます。

• 形式とタイプ

• リンク数

• 重複ブロック

• 不正なブロック番号

• i ノードのサイズ

i ノードのフォーマットとタイプ

各 i ノードには、そのタイプと状態を記述するモードのワードが入っています。i ノードには、次の 6 つのタイプがあります。

• 通常ファイル

• ディレクトリ

• ブロック型特殊ファイル

• キャラクタ型特殊ファイル

• FIFO (名前付きパイプ)

• シンボリックリンク

• シャドウ (ACL で使用される)

• ソケット

i ノードの状態は、次の 3 つに分かれています。

• 割り当て済み

• 未割り当て

• 不完全に割り当て済み

ファイルシステムが作成されると、一定数の i ノードが確保されますが、必要になるまでは割り当てられません。割り当て済みの i ノードとは、ファイルを指す i ノードです。未割り当ての i ノードは、ファイルを指さないので空のはずです。不完全に割り当て済みの状態は、i ノードが正しくフォーマットされていないことを意味します。たとえば、ハードウェア障害が原因で i ノードに不正なデータが書き込まれると、i ノードは不完全に割り当て済みの状態になることがあります。fsck が実行できる唯一の修正動作は、その i ノードを消去することです。

リンク数のチェック

各 i ノードには、そこにリンクされているディレクトリエントリ数が入っています。fsck プログラムは、ルートディレクトリから順番にディレクトリ構造全体を検査し、i ノードごとに実際のリンク数を計算して、各 i ノードのリンク数を検査します。

i ノードに格納されているリンク数が fsck によって判断された実際のリンク数と一致しない場合は、次の 3 つの状況が考えられます。

• 格納されたリンク数が 0 でなく、実際のリンク数が 0 の場合

  この状況は、i ノードにリンクされているディレクトリエントリが存在しない場合に発生することがあります。この場合、fsck はリンクされていないファイルを lost+found ディレクトリに入れます。

• 格納されたリンク数が 0 でなく、実際のリンク数も 0 でないが、2 つのリンク数が等しくない場合

  この状況は、ディレクトリエントリが追加または削除されたが、i ノードが更新されていない場合に発生することがあります。この場合、fsck はリード内のリンク数を実際のリンク数で置き換えます。

• 格納されたリンク数が 0 で実際のリンク数が 0 でない場合

  この場合、fsck は i ノード内のリンク数を実際のリンク数に変更します。

重複ブロックのチェック

各 i ノードには、それが使用するすべてのブロックのリスト、またはリストを指すポインタ (間接ブロック) が入っています。間接ブロックは i ノードによって所有されるので、間接ブロックの整合性が失われると、それを所有する i ノードが直接影響を受けます。

fsck プログラムは、i ノードから使用される各ブロック番号を、割り当て済みブロックのリストと比較します。別の i ノードからすでにブロック番号が使用されていると、そのブロック番号は重複ブロックのリストに入れられます。それ以外の場合は、割り当て済みブロックのリストが更新され、ブロック番号が追加されます。

重複ブロックがあると、fsck は再び i ノードリストを調べて、各重複ブロックを使用する他の i ノードを検索します (i ノード内に大量の重複ブロックが入っている場合は、ファイルシステムに間接ブロックが正しく書き込まれていない可能性があります)。どの i ノードにエラーがあるかを正確に判断することはできません。fsck プログラムは、保持する i ノードと消去する i ノードを選択するように促すプロンプトを表示します。

不正なブロック番号のチェック

fsck プログラムは、i ノードから使用される各ブロック番号をチェックして、その値が最初のデータブロック番号よりも大きく、ファイルシステム内の最後のデータブロック番号より小さいかどうかを調べます。ブロック番号がこの範囲に含まれない場合は、不正なブロック番号と見なされます。

間接ブロックがファイルシステムに正しく書き込まれていないことが原因で、i ノード内に不正なブロック番号が発見されることがあります。fsck はその i ノードの消去を促すプロンプトを表示します。

i ノードサイズのチェック

各 i ノードには、参照するデータブロック数が入っています。実際のデータブロック数は、割り当て済みのデータブロック数と間接ブロック数の合計です。fsck はデータブロック数を計算し、そのブロック数を i ノードから使用されるブロック数と比較します。i ノードに不正なブロック数が入っていると、fsck はその修正を促すプロンプトを表示します。

各 i ノードには、64 ビットのサイズフィールドがあります。このフィールドは、i ノードに関連付けられたファイル内の文字数 (データバイト数) を示します。i ノードのサイズフィールドに整合性があるかどうかは、サイズフィールド内の文字数を使用して、i ノードに関連付けるべきブロック数を計算し、その結果を i ノードから使用される実際のブロック数と比較して概算でチェックされます。

間接ブロック

間接ブロックは i ノードによって所有されます。したがって、間接ブロック内の整合性が失われると、それを所有する i ノードが影響を受けます。非整合性は、次の面からチェックできます。

• すでに別の i ノードから使用されているブロック

• ファイルシステムの範囲に含まれないブロック番号

また、間接ブロックに対して整合性チェックも実行されます。

データブロック

i ノードは、3 種類のデータブロックを直接または間接に参照できます。参照されるブロックは、すべて同じ種類でなければなりません。次の 3 種類のデータブロックがあります。

• プレーンデータブロック

• シンボリックリンクデータブロック

• ディレクトリデータブロック

プレーンデータブロックには、ファイルに格納される情報が入っています。シンボリックリンクデータブロックには、シンボリックリンクに格納されるパス名が入っています。ディレクトリデータブロックには、ディレクトリエントリが入っています。fsck はディレクトリデータブロックの妥当性しかチェックできません。

ディレクトリは、i ノードの mode フィールド内のエントリによって通常ファイルと区別されます。ディレクトリに関連付けらたデータブロックには、ディレクトリエントリが入っています。ディレクトリデータブロックの非整合性は、次の面からチェックされます。

• 未割り当ての i ノードを指すディレクトリ内の i ノード番号

• ファイルシステム内の i ノード番号より大きいディレクトリ内の i ノード番号

• 「.」と「..」ディレクトリには許されないディレクトリ内の i ノード番号

• ファイルシステムから切り離されたディレクトリ

未割り当てディレクトリのチェック

ディレクトリデータブロック内の i ノード番号が未割り当て i ノードを指す場合、fsck はそのディレクトリエントリを削除します。この状況は、ディレクトリエントリが入っているデータブロックが変更されて書き出されたが、i ノードが書き込まれていない場合に発生します。また、警告なしに CPU が停止された場合にも発生します。

不正な i ノード番号のチェック

ディレクトリエントリの i ノード番号が i ノードリストの最後を超える位置を指す場合、fsck はそのディレクトリエントリを削除します。この状況は、不正なデータがディレクトリのデータブロックに書き込まれると発生します。

不正な「.」と「..」エントリ

「.」ディレクトリの i ノード番号は、ディレクトリデータブロックの最初のエントリでなければなりません。また、それ自体を参照しなければなりません。つまり、その値はディレクトリデータブロックの i ノード番号に等しくなければなりません。

「..」ディレクトリの i ノード番号は、ディレクトリデータブロックの第 2 のエントリでなければなりません。その値は、親ディレクトリの i ノード番号 (または、ディレクトリがルートディレクトリの場合は、それ自体の i ノード番号) に等しくなければなりません。

「.」と「..」ディレクトリの i ノード番号が不正であれば、fsck は正しい値に置き換えます。ディレクトリへのハードリンクが複数個あると、最初に見つかった方が「..」が指す実際の親であると見なされます。この場合、fsck は他の名前を削除するように促すプロンプトを表示します。

切り離されたディレクトリ

fsck プログラムは、ファイルシステム全体で参照関係をチェックします。ファイルシステムにリンクされていないディレクトリが見つかると、fsck はそのディレクトリをファイルシステムの lost+found ディレクトリにリンクします (i ノードはファイルシステムに書き込まれてたが、それに対応するディレクトリデータブロックが書き込まれていないと、この状態が発生することがあります)。

通常データブロック

通常ファイルに関連付けられたデータブロックには、ファイルの内容が入っています。fsck は、通常ファイルのデータブロックの内容が有効かどうかはチェックしません。

fsck 要約メッセージ

fsck を対話式で実行して正常に終了すると、次のようなメッセージが表示されます。

# fsck /dev/rdsk/c0t0d0s7
** /dev/rdsk/c0t0d0s7
** Last Mounted on /export/home
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
2 files, 9 used, 2833540 free (20 frags, 354190 blocks,  0.0% fragmentation)
# 

fsck 出力の最後の行は、ファイルシステムについて次のような情報を記述します。

ブート時のファイルシステムチェック機能の変更

ブート中には、ブートスクリプト /sbin/rcS を使用して、ハードディスクからマウントされるファイルシステムごとに予備チェックが実行されます。このスクリプトは、ルート (/)、/usr および /var のファイルシステムをチェックします。他の rc シェルスクリプトが、fsck コマンドを使用して他のファイルシステムを順番にチェックします。ファイルシステムが並行にチェックされることはありません。「fsck pass」の数値が 1 より大きい場合も、ブート中にはファイルシステムは順番にチェックされます。

/etc/vfstab ファイル

ファイルシステムを直接指定せずに、ファイルシステムをチェックしたりマウントするコマンドを実行すると、各コマンドは、ファイルシステムテーブル (/etc/vfstab) を調べ、各種フィールドで指定された情報を使用して処理を行います。fsck pass フィールドは、ファイルシステムチェックのための情報を指定します。「mount at boot」フィールドは、ブート時にファイルシステムをマウントするための情報を指定します。

新しいファイルシステムを作成する場合は、ブート時にチェックするかどうかとマウントするかどうかを示すエントリを /etc/vfstab に追加します。/etc/vfstab ファイルにエントリを追加する方法の詳細は、第 36 章「ファイルシステムのマウントとマウント解除 (手順)」を参照してください。

/etc/vfstab ファイル内の情報は、各システムのスライスとファイルシステムに固有です。次の例は、/etc/vfstab ファイルを示しています。

$ more /etc/vfstab
#device         device          mount           FS      fsck    mount    mount
#to mount       to fsck         point           type    pass    at boot  options
#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr          ufs     1       yes     -
/proc           -               /proc           proc    -       no      -
fd              -               /dev/fd         fd      -       no      -
swap            -               /tmp            tmpfs   -       yes     -
 
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 /          ufs     1       no      -
/dev/dsk/c0t0d0s1 -                  -          swap    -       no      -
/dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr       ufs     2       no      -
/dev/dsk/c0t0d0s7 /dev/rdsk/c0t0d0s7 /opt       ufs     3       yes     -
pluto:/usr/dist	-    				/usr/dist       nfs     no      yes     -
$

表 39-3 に、「fsck pass」フィールドの機能を示します。

preen モードでは (-o p オプション)、fsck は 1 ディスクごとに 1 つしか有効なファイルシステムをチェックできず、あるチェックが完了した後でなければ次のチェックを開始しません。fsck は、ファイルシステムが存在するデバイスのメジャー番号とマイナー番号を使用して、自動的に異なるディスク上のファイルシステムを同時にチェックする方法を決定します。

fsck pass 番号が 1 であれば、ファイルシステムは /etc/vfstab ファイルに表示される順番にチェックされます。通常、ルート (/) ファイルシステムの fsck pass は 1 に設定されます。

fsck は、fsck pass 番号を使用せずにファイルシステムのチェック順を決定します。

ブート中に実行されるファイルシステムチェック機能を変更する方法

1. スーパーユーザーになります。

2. 「fsck pass」フィールド内の /etc/vfstab エントリを編集し、編集結果を保存します。

   次にシステムをブートしたときに、新しい値が使用されます。

UFS ファイルシステムを対話式でチェックして修復する

次の場合には、ファイルシステムを対話式でチェックする必要があります。

• マウントできない場合

• 使用中に問題が発生する場合

使用中のシステムの整合性が失われると、コンソールウィンドウにエラーメッセージが表示されたり、システムがクラッシュしたりすることがあります。

fsck を使用する前に、「fsck コマンドの構文とオプション」 と『Solaris のシステム管理 (第 2 巻)』の「ファイルシステムで発生する問題の解決」を参照してください。

ファイルシステムのチェックが必要かどうかを調べる方法

1. スーパーユーザーになります。

2. ファイルシステムがマウントされている場合、マウントを解除します。

   # umount /mount-point

3. ファイルシステムをチェックします。

   # fsck -m /dev/rdsk/device-name

   このコマンドで指定したファイルシステムのスーパーブロック内の状態フラグがチェックされ、ファイルシステムがクリーンであるか、あるいはチェックする必要があるかどうかが判断されます。

   デバイス引数を省略すると、/etc/vfstab 内で「fsck pass」の値が 0 より大きいすべての UFS ファイルシステムがチェックされます。

例 - ファイルシステムのチェックが必要かどうかを調べる

次の例では、ファイルシステムのチェックが必要なことを示しています。

# fsck -m /dev/rdsk/c0t0d0s6
** /dev/rdsk/c0t0d0s6
ufs fsck: sanity check: /dev/rdsk/c0t0d0s6 needs checking

ファイルシステムを対話式でチェックする方法

1. スーパーユーザーになります。

2. ルート (/) と /usr 以外のローカルファイルシステムをマウント解除します。

   # umountall -l

3. ファイルシステムをチェックします。

   # fsck

   /etc/vfstab ファイル内で、「fsck pass」フィールド内のエントリが 0 より大きいすべてのファイルシステムがチェックされます。また、fsck の引数として、マウントポイントディレクトリや /dev/rdsk/device-name も指定できます。整合性が失われている場合には、そのことを示すメッセージが表示されます。エラーメッセージのプロンプトに応答して 1 つまたは複数の UFS ファイルシステムを対話式でチェックする方法については、『Solaris のシステム管理 (第 2 巻)』の「ファイルシステムで発生する問題の解決」 を参照してください。

   ---

   注意 -

   マウントされているファイルシステム上で fsck を実行すると、fsck がなんらかの変更を行なった場合、システムがクラッシュする可能性があります。ただし、たとえばシングルユーザーモードで fsck を実行してファイルシステムを修復する場合などは除きます。

   ---

4. エラーを修正し終わったら、fsck と入力して Return キーを押します。

   fsck は、一度の実行ですべてのエラーを修正できないことがあります。「FILE SYSTEM STATE NOT SET TO OKAY」というメッセージが表示される場合は、fsck を使って、修正作業を繰り返します。fsck では修正できない場合は、「fsck で修復できない UFS ファイルシステムを修正する方法」を参照してください。

5. lost+found ディレクトリに保存されているファイルの名前を変更して移動します。

   fsck によって lost+found ディレクトリに入れられた各ファイル名は、その i ノード番号を使用して変更されます。可能であれば、ファイル名を変更し、ファイルが含まれるディレクトリに移動してください。grep コマンドを使用して各ファイル中の語句を探したり、file コマンドを使用してファイルタイプを識別できる場合もあります。ディレクトリ全体が lost+found に書き出されている場合の方が、復帰先のディレクトリを調べて、移動することは容易です。

例 - ファイルシステムを対話方式でチェックする

次の例では、/dev/rdsk/c0t0d0s6 がチェックされ、不正なブロック数が訂正されます。

# fsck /dev/rdsk/c0t0d0s6
checkfilesys: /dev/rdsk/c0t0d0s6
** Phase 1 - Check Block and Sizes
INCORRECT BLOCK COUNT I=2529 (6 should be 2)
CORRECT? y

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Cylinder Groups
929 files, 8928 used, 2851 free (75 frags, 347 blocks, 0.6%
fragmentation)
/dev/rdsk/c0t0d0s6 FILE SYSTEM STATE SET TO OKAY

***** FILE SYSTEM WAS MODIFIED *****

UFS ファイルシステムの修復

fsck の修復オプション (-o p) は、UFS ファイルシステムをチェックし、単純な問題を自動的に修正します。通常、この種の問題は予期しないシステム停止によるものです。オペレータの介入が必要な問題が発見されると、このコマンドは即座に終了します。また、修復オプションを使用する場合には、ファイルシステムを並列にチェックすることも可能です。

状態がクリーンにマークされずにシステムが停止した後のファイルシステムの修復にも、-o p オプションを指定して fsck を実行することができます。このモードでは、fsck はクリーンフラグを調べずに完全チェックを実行します。これらの処理は、fsck を対話形式で実行した場合の処理のサブセットです。

ファイルシステムを修復する方法

1. スーパーユーザーになります。

2. ファイルシステムをマウント解除します。

   # umount mount-point

3. 修復オプションを指定して UFS ファイルシステムをチェックします。

   # fsck -o p /dev/rdsk/device-name

   fsck の引数として mount-point または /dev/rdsk/device-name を使用すると、個々のファイルシステムを修復できます。

例 - ファイルシステムを修復する

次の例では、/usr ファイルシステムが修復されます。

# fsck -o p /usr

不正なスーパーブロックの復元

ファイルシステムのスーパーブロック内のデータが破壊された場合は、復元しなければなりません。スーパーブロックが不正なときには、fsck からメッセージが表示されます。幸い、スーパーブロックの冗長コピーがファイルシステム内に格納されています。fsck -o b を使用すると、スーパーブロックをそのコピーで置き換えることができます。

不正なスーパーブロックを復元する方法

1. スーパーユーザーになります。

2. データが破壊されたファイルシステム上のディレクトリがカレントディレクトリになっている場合は、カレントディレクトリを変更します。

3. ファイルシステムをマウント解除します。

   # umount mount-point

   ---

   注意 -

   次の手順では、必ず newfs -N オプションを使用してください。-N オプションを省略すると、新しい空のファイルシステムが作成されます。

   ---

4. newfs -N コマンドを使用して、スーパーブロックの値を表示します。

   # newfs -N /dev/rdsk/device-name

   このコマンドの出力には、newfs によってファイルシステムが作成されたときに、スーパーブロックのコピーとして使用されることになったブロック番号が表示されます。カスタマイズされたファイルシステムを作成する方法については、「カスタムファイルシステムパラメータの決定」を参照してください。

5. fsck コマンドを使用して、代替スーパーブロックを指定します。

   # fsck -F ufs -o b=block-number /dev/rdsk/device-name

   fsck は、指定された代替スーパーブロックを使用して、一次スーパーブロックを復元します。いつでも代替ブロックとして 32 を試すことができます。また、newfs -N で表示された代替ブロックを使用することもできます。

例 - 不正なスーパーブロックを復元する

次の例では、/files7 ファイルシステムのスーパーブロックがブロック番号 5264 に存在するコピーを使って復元されます。

# cd /
# umount /files7
# newfs -N /dev/rdsk/c0t3d0s7
/dev/rdsk/c0t3d0s7: 163944 sectors in 506 cylinders of 9 tracks, 36 sectors
 83.9MB in 32 cyl groups (16 c/g, 2.65MB/g, 1216 i/g)
super-block backups (for fsck -b #) at:
 32, 5264, 10496, 15728, 20960, 26192, 31424, 36656, 41888,
 47120, 52352, 57584, 62816, 68048, 73280, 78512, 82976, 88208,
 93440, 98672, 103904, 109136, 114368, 119600, 124832, 130064, 135296,
 140528, 145760, 150992, 156224, 161456,
# fsck -F ufs -o b=5264 /dev/rdsk/c0t3d0s7
Alternate superblock location: 5264.
** /dev/rdsk/c0t3d0s7
** Last Mounted on
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
36 files, 867 used, 75712 free (16 frags, 9462 blocks, 0.0% fragmentation)
/dev/rdsk/c0t3d0s7 FILE SYSTEM STATE SET TO OKAY

***** FILE SYSTEM WAS MODIFIED *****
# 

ルート (/) ファイルシステム中のスーパーブロックが破壊されていてシステムをブートできない場合は、/kernel/unix を再インストールして newfs コマンドでルートファイルシステムを再構築してください。スーパーブロックは newfs コマンドによって作成されるので、ユーザーが復元する必要はありません。

fsck で修復できない UFS ファイルシステムを修正する方法

あるパスで問題が訂正されたために、前のパスで見つからなかった問題が表面化する場合があるので、fsck を何度か実行してファイルシステムを修正しなければならないことがあります。fsck はクリーンになるまで動作を続けるわけではないので、手作業で実行しなければなりません。

fsck で表示される情報に注目してください。問題を解決する上で参考になります。たとえば、メッセージは不正なディレクトリを指す場合があります。そのディレクトリを削除すると、fsck が問題なく実行されるようになる場合もあります。

それでも fsck でファイルシステムを修復できない場合は、fsdb、ff、clri、または ncheck コマンドを使用し、間違いを指定して修正します。これらのコマンドの使用方法については、fsdb(1M)、ff(1M)、 clri(1M)、ncheck(1M) の各マニュアルページを参照してください。最終的には、ファイルシステムを作成し直し、その内容をバックアップ媒体から復元せざるを得ない場合があります。ファイルシステム全体を復元する方法については、第 44 章「ファイルとファイルシステムの復元 (手順)」を参照してください。

ファイルシステムを完全に修復できないが、読み取り専用としてマウントできる場合は、cp、tar、または cpio を使用して、データのすべてまたは一部をファイルシステムから取り出してください。

問題の原因がハードウェア上のディスクエラーであれば、ファイルシステムを作成し直して復元する前に、ディスクをフォーマットし直して再びスライスに分割しなければならない場合があります。一般に、ハードウェアエラーが発生すると、さまざまなコマンドで同じエラーが繰り返し表示されます。format(1M) コマンドはディスク上の不良ブロックを使用しないようにします。ただし、ディスクの損傷が致命的な場合、フォーマットし直した後も問題が解決されないことがあります。format コマンドの使用方法については、format(1M) のマニュアルページを参照してください。新しいディスクをインストールする方法については、第 30 章「SPARC: ディスクの追加 (手順)」または第 31 章「IA: ディスクの追加 (手順)」を参照してください。

fsck コマンドの構文とオプション

fsck コマンドは、ファイルシステム内の非整合状態をチェックして修復します。次の 4 つのオプションがあります。

• ファイルシステムがマウント可能かどうかのチェックだけを行う (fsck -m)

• 修復する前に確認を促すプロンプトを表示する (fsck)

• すべての修復時のプロンプトに yes または no の応答が指定されたものとして処理を行う (fsck -y または fsck -n)

• 確認を促すプロンプトを表示することなくファイルシステムを修復し、想定される (軽微な) 非整合箇所をすべて修復 (preen) するが、重大な問題にぶつかると終了する (fsck -o p)

汎用 fsck コマンドの構文、オプション、引数

fsck には、汎用コマンドとファイルシステム固有のコマンドの 2 種類があります。汎用コマンドはほとんどのタイプのファイルシステムに使用でき、固有のコマンドは特定のタイプのファイルシステムにのみ使用できます。通常は固有コマンドを使用してください。汎用コマンドは必要に応じてファイルシステム固有のコマンドを呼び出します。

通常、fsck を実行するにはスーパーユーザーにならなければなりません。スーパーユーザーにならなくても fsck コマンドの実行はできますが、修復するにはファイルシステムをマウント解除しなければなりません。また、スライスの raw デバイスファイルの読み取り権を持っていなければなりません (セキュリティ上の問題のため、一般のユーザーには raw デバイスファイルの読み取り権はありません)。

汎用 fsck コマンドは、/etc/vfstab にアクセスして、どのファイルシステムをチェックするかを調べます。fsck pass 番号 に - (ハイフン) が指定されている任意のファイルシステムと、0 が指定されている UFS のファイルシステムを除き、指定された各ファイルシステム上で、該当するファイルシステム専用の fsck コマンドを実行します。

汎用 fsck コマンドの構文は次のとおりです。

/usr/sbin/fsck [-F type] [-V] [-m] [special]
/usr/sbin/fsck [-F type] [-V] -[y|Y]|[n|N] [-o specific-options][special]

表 39-4 に、汎用 fsck コマンドのオプションと引数を示します。