Solaris のシステム管理 (基本編)

第 43 章 UFS ファイルシステムの整合性チェック (手順)

この章では、UFS ファイルシステムの整合性チェックに関する概要と手順について説明します。

この章で説明する手順は次のとおりです。

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

fsck のエラーメッセージについては、『Solaris のシステム管理 (上級編)』の「UFS ファイルシステムの不整合解決 (手順)」を参照してください。

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

ファイルシステムの整合性

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

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

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

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

i ノードについては、i ノードを参照してください。

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

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

スーパーブロックについては、スーパーブロックを参照してください。

次の表に状態フラグの値とその説明を示します。

表 43–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 マークが付いたファイルシステムは、マウント前のチェックをスキップできる。ファイルシステムの状態が FSCLEANFSSTABLE 、または FSLOG のいずれでもない場合は、mount コマンドによってファイルシステムを読み取り / 書き込み用にマウントできない。

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

表 43–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 秒間隔で) 実行すると、インコア情報を反映するようにディスク情報が更新されます。システムがインコア情報を書き込まずに停止すると、ディスク上のファイルシステムの整合性がなくなります。

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

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

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

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

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

UFS ファイルシステム構造については、UFS ファイルシステムのシリンダグループの構造を参照してください。

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

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

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

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

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

UFS ファイルシステム構造の詳細については、UFS ファイルシステムのシリンダグループの構造を参照してください。

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

空きブロック数は、シリンダグループのブロックマップに格納されます。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 ノードには、次の 9 つのタイプがあります。

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

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

リンク数のチェック

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

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

重複ブロックのチェック

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

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

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

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

ディレクトリデータブロック内の 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 出力の最後の行は、ファイルシステムについて次のような情報を記述します。

# files

使用中の i ノード数 

# used

使用中のフラグメント数 

# free

未使用のフラグメント数 

# frags

未使用の非ブロックフラグメント数 

# blocks

未使用の完全ブロック数 

% fragmentation

断片化の比率。ファイルシステム内の空きフラグメント × 100 / 全フラグメント 

フラグメントについては、フラグメントサイズを参照してください。

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

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

使用中のファイルシステムの整合性が失われると、コンソールウィンドウやシステムメッセージファイルにエラーメッセージが出力されたり、システムがクラッシュしたりすることがあります。たとえば、システムメッセージファイル /var/adm/messages に次のようなメッセージが出力されることがあります。


Sep  5 13:42:40 hostname ufs: [ID 879645 kern.notice] NOTICE: /: unexpected
free inode 630916, run fsck(1M)

hostname は、エラーを報告したシステムです。

fsck コマンドを使用する前に、fsck のエラーメッセージの解決方法について、fsck コマンドの構文とオプションおよび『Solaris のシステム管理 (上級編)』の「UFS ファイルシステムの不整合解決 (手順)」を参照してください。

fsck コマンドを実行して UFS ファイルシステムをチェックするときには、次の点を考慮してください。

代替ブートデバイスからルート (/) ファイルシステムまたは /usr ファイルシステムをチェックする方法

この手順では、ローカル CD またはネットワークブートサーバーを利用でき、代替デバイスからシステムをブートできることを前提とします。

不正なスーパーブロックの復元については、不正なスーパーブロックを復元する方法を参照してください。

  1. スーパーユーザーになるか、同等の役割を引き受けます。

  2. ルート (/) ファイルシステムがミラー化されているシステムの場合は、まずルート (/) ミラーを切り離して、その後で代替デバイスからブートしてください。接続した状態で操作すると、ファイルシステムが破壊する可能性があります。

    ルート (/) ミラーの切り離しについては、『Solaris ボリュームマネージャの管理』の「サブミラーに関する作業」を参照してください。

  3. チェックの必要なルート (/) ファイルシステムまたは /usr ファイルシステムのデバイス (/dev/dsk/c0t0d0s0 など) を特定します。

    このデバイス名は、代替デバイスからブートした後で指定する必要があります。代替デバイスからブートした後でデバイスを特定するのは簡単ではありません。

  4. チェックの必要なルート (/) ファイルシステムまたは /usr ファイルシステムのあるシステムを、ローカル CD またはネットワークなどの代替デバイスからブートします。このとき、これらのファイルシステム上でほかの動作が存在しないように、シングルユーザーモードでブートしてください。

    たとえば、次のように入力します。


    # init 0
    ok boot net -s
    .
    .
    .
    #
  5. 手順 3 で特定したルート (/) ファイルシステムまたは /usr ファイルシステムが含まれるデバイスをチェックします。

    チェックまたは修復するファイルシステムのハードウェアが変更されている場合には、そのデバイス名も変更されている可能性があります。 fsck -n メッセージの「Last Mounted on ...」を利用して、そのファイルシステムのデバイスが予期したデバイスであることを確認してください。

    たとえば、チェックするルートファイルシステムが /dev/dsk/c0t0d0s0 の場合は、次のように出力されます。


    # fsck -n /dev/rdsk/c0t0d0s0
    ** /dev/rdsk/c0t0d0s0 (NO WRITE)
    ** Last Mounted on /
    .
    .
    .
    fsck /dev/rdsk/c0t0d0s0
    ** /dev/rdsk/c0t0d0s0
    ** Last Mounted on /
    ** Phase 1 - Check Blocks and Sizes
    ** Phase 2 - Check Pathnames
    .
    .
    .
  6. 報告された fsck エラーをすべて修正します。

    1 つまたは複数の UFS ファイルシステムを対話式でチェックしながら、エラーメッセージのプロンプトに応答する方法については、『Solaris のシステム管理 (上級編)』の「UFS ファイルシステムの不整合解決 (手順)」を参照してください。

  7. FILE SYSTEM STATE NOT SET TO OKAY」や「FILE SYSTEM MODIFIED」などのメッセージが表示される場合は、必要に応じて fsck コマンドをもう一度実行してください。

    fsck コマンドは、一度の実行ではすべてのエラーを修正できないことがあります。

    fsck コマンドを何度か実行してもすべての問題を修復できない場合は、fsck コマンドで修復できない UFS ファイルシステムの修正を参照してください。

  8. 修復したファイルシステムをマウントして、 lost+found ディレクトリにファイルが存在するかどうかを確認します。

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

    どうしても特定できないファイルまたはディレクトリについては、 lost+found ディレクトリからそれらを削除して、不要な領域を解放してください。

  9. システムをマルチユーザーモードに戻します。


    # init 6
    

    代替デバイスからシングルユーザーモードでブートしている場合には、Control + D を押すと、Solaris のインストール処理が開始されます。

  10. ルート (/) ファイルシステムがミラー化されているシステムの場合のみ、ルート (/) ミラーを再接続します。

ルート (/) 以外、または /usr 以外のファイルシステムをチェックする方法

この手順では、チェックするファイルシステムがマウント解除されていることを前提としています。

不正なスーパーブロックの復元については、不正なスーパーブロックを復元する方法を参照してください。

  1. スーパーユーザーになるか、同等の役割を引き受けます。

  2. 最初にローカルファイルシステムをマウント解除し、ファイルシステム上でほかの動作が存在しないようにします。

    fsck コマンドの引数として、マウントポイントディレクトリや /dev/dsk/ device-name を指定します。整合性が失われている場合には、そのことを示すメッセージが表示されます。

    たとえば、次のように入力します。


    # umount /export/home
    # fsck /dev/rdsk/c0t0d0s7
    ** /dev/dsk/c0t0d0s7
    ** Last Mounted on /export/home
    .
    .
    .
  3. 報告された fsck エラーをすべて修正します。

    1 つまたは複数の UFS ファイルシステムを対話式でチェックしながら、エラーメッセージのプロンプトに応答する方法については、『Solaris のシステム管理 (上級編)』の「UFS ファイルシステムの不整合解決 (手順)」を参照してください。

  4. FILE SYSTEM STATE NOT SET TO OKAY」や「FILE SYSTEM MODIFIED」というメッセージが表示される場合は、必要に応じて fsck コマンドをもう一度実行してください。

    fsck コマンドは、一度の実行ではすべてのエラーを修正できないことがあります。

    fsck コマンドを何度か実行してもすべての問題を修復できない場合は、fsck コマンドで修復できない UFS ファイルシステムの修正を参照してください。

  5. 修復したファイルシステムをマウントして、 lost+found ディレクトリにファイルが存在するかどうかを確認します。

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

    どうしても特定できないファイルまたはディレクトリについては、 lost+found ディレクトリからそれらを削除して、不要な領域を解放してください。

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

例 — ルート (/) 以外、または /usr 以外のファイルシステムを対話式でチェックする

次の例は、/dev/rdsk/c0t0d0s6 ファイルシステムをチェックし、不正なブロック数を訂正する方法を示しています。この例では、ファイルシステムがマウント解除されていることを前提としています。


# fsck /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 コマンド (p は修復用) は、UFS ファイルシステムをチェックし、通常は予期しないシステムのシャットダウンによって発生する問題を自動的に修正します。オペレータの介入が必要な問題が発見されると、このコマンドは即座に終了します。このコマンドによって、ファイルシステムを並列にチェックすることも可能です。

システムがクリーンな状態でシャットダウンしなかった後のファイルシステムの修復にも、fsck -o p コマンドを実行することができます。このモードでは、fsck コマンドはクリーンフラグを調べずに完全チェックを実行します。これらの処理は、fsck コマンドを対話式で実行した場合の処理のサブセットです。

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

この手順では、ファイルシステムがマウント解除されているか、非アクティブであることを前提としています。

  1. スーパーユーザーになるか、同等の役割を引き受けます。

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


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


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

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

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

次の例は、/export/home ファイルシステムの修復方法を示します。


# fsck -o p /export/home

fsck コマンドで修復できない UFS ファイルシステムの修正

fsck コマンドを何度か実行しているとき、問題の修正を進めていく過程で、以前の実行で検出されていた問題が再度発生することがあります。このような場合には、問題が報告されなくなるまで fsck コマンドを繰り返し実行して、すべてのエラーを検出および修正する必要があります。fsck コマンドはすべての問題を修正するまで動作を続けるわけではないので、手作業で再実行しなければなりません。

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

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

ファイルシステム全体を復元する方法については、第 49 章「ファイルとファイルシステムの復元 (手順)」を参照してください。

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

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

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

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

スーパーブロックの詳細については、スーパーブロックを参照してください。

ルート (/) ファイルシステム内のスーパーブロックが損傷し、修復できない場合は、次のどちらかの操作を実行します。

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

  1. スーパーユーザーになるか、同等の役割を引き受けます。

  2. 不正なスーパーブロックがルート (/) または /usr ファイルシステム内にあるかどうかを調べ、次のどちらかの操作を実行します。

    1. 不正なスーパーブロックがルート (/) または /usr ファイルシステム内にある場合は、システムをいったん停止し、ネットワークまたはローカル接続された CD からブートします。

      ローカル接続された CD からブートする場合は、次のコマンドを使用します。


      ok boot cdrom -s
      

      ブートサーバーまたはインストールサーバーがすでに設定済みのネットワークからブートする場合は、次のコマンドを使用します。


      ok boot net -s
      

      システムを停止する方法については、SPARC: 復元を目的としてシステムを停止する方法または x86: 復元を目的としてシステムを停止する方法を参照してください。

    2. 不正なスーパーブロックがルート (/) または /usr ファイルシステム内にない場合は、損傷したファイルシステム以外のディレクトリに移動し、ファイルシステムをマウント解除します。


      # umount /mount-point
      

      注意 – 注意 –

      次の手順では、必ず newfs -N オプションを使用してください。-N オプションを指定しない場合は、そのファイルシステムのデータがすべて破壊され、空のファイルシステムに置き換わります。


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


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

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

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


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

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

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

次の例は、スーパーブロックのコピー 5264 を復元する方法を示しています。


# 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 *****
# 

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

fsck コマンドは、ファイルシステム内の不整合をチェックして修復します。オプションを指定しないで fsck コマンドを実行した場合は、修復が行われる前に確認を求めるプロンプトが表示されます。このコマンドには、次の 4 つのオプションがあります。

コマンドとオプション 

説明 

fsck -m

ファイルシステムがマウント可能かどうかのチェックを行う 

fsck -y

すべての修復に対して yes の応答が指定されたものとして処理を行う 

fsck -n

すべての修復に対して no の応答が指定されたものとして処理を行う 

fsck -o p

確認を求めるプロンプトを表示することなく、ファイルシステムを修復し、想定される (軽微な) 不整合箇所をすべて修正するが、重大な問題が見つかると終了する