この章では、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 に状態フラグの値とその説明を示します。
表 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 マークが付いたファイルシステムは、マウント前のチェックをスキップできる。ファイルシステムの状態が FSCLEAN 、FSSTABLE 、または 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 コマンド (チェックおよび修復ユーティリティ) で検出される問題、およびそれらの修正方法について説明します。
就業日には毎日多数のファイルが作成、変更、または削除されます。ファイルが変更されるたびに、オペレーティングシステムは一連のファイルシステムの更新処理を実行します。これらの更新処理がディスクに確実に書き込まれると、ファイルシステムの整合性が保たれます。
ユーザープログラムが書き込みなどの、ファイルシステムを変更する処理を実行すると、書き込まれるデータはまずカーネルのインコアバッファーにコピーされます。一般に、ディスクの更新は非同期に処理されます。このため、ユーザープロセスは、書き込みシステムコールが値を返した後すぐに処理を続けることができますが、実際のデータの書き込みは、ずいぶん後に実行されることもあります。したがって、ディスク上にあるファイルシステムは、インコア情報で表されるファイルシステムの状態から常に遅延することになります。
別の目的にバッファーが必要になったり、カーネルが fsflush デーモンを自動的に (30 秒間隔で) 実行すると、インコア情報を反映するようにディスク情報が更新されます。システムがインコア情報を書き込まずに停止すると、ディスク上のファイルシステムの整合性がなくなります。
ファイルシステムの整合性は、さまざまな原因で失われることがあります。最も一般的な原因は、オペレータのエラーとハードウェア障害です。
システムを正しくシャットダウンしなかったり、マウントされているファイルシステムが正しくオフラインにされないと、「クリーンでない停止」が原因で問題が発生することがあります。クリーンでないシャットダウンを防ぐには、システムをシャットダウンしたり、ディスクをドライブから物理的に取り出したり、ディスクをオフライン状態にしたりする前に、ファイルシステムの現在の状態をディスクに書き込まなければなりません。つまり、「同期」させなければなりません。
また、ハードウェアの欠陥が原因で整合性が失われることもあります。ディスクドライブ上ではいつでもブロックが損傷する可能性があり、ディスクコントローラが正常に機能しなくなる可能性があります。
この節では、UFS ファイルシステムの構成要素、つまりスーパーブロック、シリンダグループブロック、i ノード、間接ブロック、データブロックに fsck コマンドが適用する整合性チェックの種類について説明します。
UFS ファイルシステム構造については、UFS ファイルシステムのシリンダグループの構造を参照してください。
スーパーブロックには集計情報が格納されており、UFS ファイルシステム内で最も破損しがちな構成要素です。ファイルシステムの i ノードやデータブロックが変更されるたびに、スーパーブロックも変更されます。CPU が停止した場合、直前のコマンドが sync コマンドでなければ、スーパーブロックはほぼ確実に破損しています。
スーパーブロックの不整合は、次の面からチェックされます。
ファイルシステムのサイズ
i ノード数
空きブロック数
空き i ノード数
ファイルシステムのサイズは、スーパーブロックと i ノードリストに使用されるブロック数よりも大きくなければなりません。i ノード数は、ファイルシステムの最大許容数よりも小さくなければなりません。i ノードは、ファイルに関するすべての情報を表します。ファイルシステムのサイズとレイアウト情報は、fsck コマンドにとって最も重要な情報部分です。これらのサイズはファイルシステムの作成時に静的に決められるため、実際にチェックする方法はありません。ただし、fsck コマンドを使用してサイズが妥当な範囲内にあるかどうかはチェックできます。ファイルシステムの他のすべてのチェックを行うには、これらのサイズが正確でなければなりません。fsck コマンドが一次スーパーブロックの静的パラメータ内に不正な情報を検出すると、オペレータに代替スーパーブロックの位置を指定するように促します。
UFS ファイルシステム構造の詳細については、UFS ファイルシステムのシリンダグループの構造を参照してください。
空きブロック数は、シリンダグループのブロックマップに格納されます。fsck コマンドは、空きマーク付きのすべてのブロックがファイルによって使用されていないかどうかをチェックします。すべてのブロックをチェックし終わると、fsck コマンドは空きブロック数と i ノードによって使用されるブロック数の合計がファイルシステム内の合計ブロック数に等しくなるかどうかをチェックします。ブロックマップ内に間違いがあると、fsck コマンドはブロックが割り当てられている状態のままで構築し直します。
スーパーブロック内の集計情報には、ファイルシステム内の空きブロックの合計数のカウントが入っています。fsck コマンドは、このブロック数をファイルシステム内で見つかった空きブロック数と比較します。数が一致しなければ、fsck コマンドはスーパーブロック内の空きブロック数を実際の空きブロック数で置き換えます。
スーパーブロック内の集計情報には、ファイルシステム内の空き i ノード数が入っています。fsck コマンドは、この i ノード数をファイルシステム内で見つかった空き i ノード数と比較します。数が一致しなければ、fsck はスーパーブロック内の空き i ノード数を実際の空き i ノード数で置き換えます。
i ノードリストは、i ノード 2 から順番にチェックされます (i ノード 0 と i ノード 1 は予約済み)。各 i ノードの不整合は、次の面からチェックされます。
形式とタイプ
リンク数
重複ブロック
不正なブロック番号
i ノードのサイズ
各 i ノードには、そのタイプと状態を記述するモードのワードが入っています。i ノードには、次の 9 つのタイプがあります。
割り当て済み
未割り当て
不完全に割り当て済み
ファイルシステムが作成されると、一定数の 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 ノードには、参照するデータブロック数が入っています。実際のデータブロック数は、割り当て済みのデータブロック数と間接ブロック数の合計です。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 ノードリストの最後を超える位置を指す場合、fsck コマンドはそのディレクトリエントリを削除します。この状況は、不正なデータがディレクトリのデータブロックに書き込まれると発生します。
「.」ディレクトリの i ノード番号は、ディレクトリデータブロックの最初のエントリでなければなりません。また、それ自体を参照しなければなりません。つまり、その値はディレクトリデータブロックの i ノード番号に等しくなければなりません。
「..」ディレクトリの i ノード番号は、ディレクトリデータブロックの第 2 のエントリでなければなりません。その値は、親ディレクトリの i ノード番号 (または、ディレクトリがルートディレクトリの場合は、それ自体の i ノード番号) に等しくなければなりません。
「.」と「..」ディレクトリの i ノード番号が不正であれば、fsck コマンドは正しい値に置き換えます。ディレクトリへのハードリンクが複数個ある場合は、最初に見つかったハードリンクが「..」が指す実際の親であると見なされます。この場合、fsck コマンドは他の名前を削除するように促すプロンプトを表示します。
fsck コマンドは、ファイルシステム全体で参照関係をチェックします。ファイルシステムにリンクされていないディレクトリが見つかると、fsck コマンドはそのディレクトリをファイルシステムの lost+found ディレクトリにリンクします。この状況は、i ノードがファイルシステムに書き込まれたが、それに対応するディレクトリデータブロックが書き込まれていない場合にも発生することがあります。
通常ファイルに関連付けられたデータブロックには、ファイルの内容が入っています。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 / 全フラグメント |
フラグメントについては、フラグメントサイズを参照してください。
次の場合には、ファイルシステムを対話式でチェックする必要があります。
マウントできない場合
使用中に不整合が発生する場合
使用中のシステムの整合性が失われると、コンソールウィンドウにエラーメッセージが表示されたり、システムがクラッシュしたりすることがあります。
fsck コマンドを使用する前に、fsck コマンドの構文とオプションおよび『Solaris のシステム管理 (上級編)』の「UFS ファイルシステムの不整合解決 (手順)」を参照してください。
スーパーユーザーになるか、同等の役割を引き受けます。
ファイルシステムがマウントされている場合、マウントを解除します。
# umount /mount-point |
ファイルシステムをチェックします。
# 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 |
スーパーユーザーになるか、同等の役割を引き受けます。
ルート (/) と /usr 以外のローカルファイルシステムをマウント解除します。
# umountall -l |
ファイルシステムをチェックします。
# fsck |
/etc/vfstab ファイル内で、「fsck pass」フィールドのエントリが 0 より大きいすべてのファイルシステムがチェックされます。また、fsck コマンドの引数として、マウントポイントディレクトリや /dev/rdsk/device-name も指定できます。整合性が失われている場合には、そのことを示すメッセージが表示されます。
1 つまたは複数の UFS ファイルシステムを対話式でチェックしながら、エラーメッセージのプロンプトに応答する方法については、『Solaris のシステム管理 (上級編)』の「UFS ファイルシステムの不整合解決 (手順)」を参照してください。
マウントされているファイルシステム上で fsck コマンドを実行すると、fsck コマンドによってなんらかの変更が行われた場合にシステムがクラッシュする可能性があります。ただし、シングルユーザーモードで fsck コマンドを実行してファイルシステムを修復する場合などは除きます。
エラーを修正し終わったら、fsck と入力して Return キーを押します。
fsck コマンドは、一度の実行ですべてのエラーを修正できないことがあります。「FILE SYSTEM STATE NOT SET TO OKAY」というメッセージが表示される場合は、fsck コマンドを使って、修正作業を繰り返します。fsck では修正できない場合は、fsck コマンドで修復できない UFS ファイルシステムの修正を参照してください。
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 ***** |
fsck -o p コマンド (p は修復用) は、UFS ファイルシステムをチェックし、通常は予期しないシステムのシャットダウンによって発生する問題を自動的に修正します。オペレータの介入が必要な問題が発見されると、このコマンドは即座に終了します。このコマンドによって、ファイルシステムを並列にチェックすることも可能です。
システムがクリーンな状態でシャットダウンしなかった後のファイルシステムの修復にも、fsck -o p コマンドを実行することができます。このモードでは、fsck コマンドはクリーンフラグを調べずに完全チェックを実行します。これらの処理は、fsck コマンドを対話式で実行した場合の処理のサブセットです。
UFS ファイルシステムをマウント解除します。
# umount /mount-point |
修復オプションを指定して UFS ファイルシステムをチェックします。
# fsck -o p /dev/rdsk/device-name |
fsck コマンドの引数として /mount-point または /dev/rdsk/device-name を使用すると、個々のファイルシステムを修復できます。
次の例は、/usr ファイルシステムを修復する方法を示しています。
# fsck -o p /usr |
あるパスで問題が訂正されたために、前のパスで見つからなかった問題が表面化する場合があるので、fsck コマンドを何度か実行してファイルシステムを修正しなければならないことがあります。fsck コマンドはクリーンになるまで動作を続けるわけではないので、手作業で再実行しなければなりません。
fsck コマンドで表示される情報に注目してください。問題を解決する上で参考になります。たとえば、メッセージは損傷したディレクトリを指している場合があります。そのディレクトリを削除すると、fsck コマンドが問題なく実行されるようになる場合もあります。
それでも fsck コマンドでファイルシステムを修復できない場合は、fsdb、ff、clri、または ncheck コマンドを使用し、間違いを指定して修正します。これらのコマンドの使用方法については、fsdb(1M)、ff(1M)、clri(1M)、ncheck(1M) の各マニュアルページを参照してください。最終的には、ファイルシステムを作成し直し、その内容をバックアップメディアから復元せざるを得ない場合があります。
ファイルシステム全体を復元する方法については、第 49 章「ファイルとファイルシステムの復元 (手順)」を参照してください。
ファイルシステムを完全に修復できないが、読み取り専用としてマウントできる場合は、cp、tar、または cpio コマンドを使用して、データのすべてまたは一部をファイルシステムから取り出してください。
問題の原因がハードウェア上のディスクエラーであれば、ファイルシステムを作成し直して復元する前に、ディスクをフォーマットし直して再びスライスに分割しなければならない場合があります。一般に、ハードウェアエラーが発生すると、さまざまなコマンドで同じエラーが繰り返し表示されます。format コマンドはディスク上の不良ブロックを使用しないようにします。ただし、ディスクの損傷が致命的な場合、フォーマットし直した後も問題が解決されないことがあります。format コマンドの使用方法については、format(1M) のマニュアルページを参照してください。新しいディスクのインストール方法については、第 34 章「SPARC: ディスクの追加 (手順)」または第 35 章「x86: ディスクの追加 (手順)」を参照してください。
ファイルシステムのスーパーブロック内のデータが破壊された場合は、復元しなければなりません。スーパーブロックが不正なときには、fsck コマンド からメッセージが表示されます。幸い、スーパーブロックのコピーがファイルシステム内に格納されています。fsck -o b コマンドを使用すると、スーパーブロックをそのいずれかのコピーで置き換えることができます。
スーパーブロックの詳細については、スーパーブロックを参照してください。
ルート (/) ファイルシステム内のスーパーブロックが損傷し、修復できない場合は、次のどちらかの操作を実行します。
システムをインストールし直す。
ネットワークまたはローカルの CD からブートし、以下の手順を実行する。それらの手順がうまくいかない場合は、newfs コマンドを使ってルート (/) ファイルシステムを作成し直し、バックアップコピーから復元する。
スーパーユーザーになるか、同等の役割を引き受けます。
不正なスーパーブロックがルート (/) または /usr ファイルシステム内にあるかどうかを調べ、次のどちらかの操作を実行します。
不正なスーパーブロックがルート (/) または /usr ファイルシステム内にある場合は、システムをいったん停止し、ネットワークまたはローカル接続された CD からブートします。
ローカル接続された CD からブートする場合は、次のコマンドを使用します。
ok boot -s cdrom |
ブートサーバーまたはインストールサーバーがすでに設定済みのネットワークからブートする場合は、次のコマンドを使用します。
ok boot -s net |
システムを停止する方法については、SPARC: 復元を目的としてシステムを停止する方法または x86: 復元を目的としてシステムを停止する方法を参照してください。
不正なスーパーブロックがルート (/) または /usr ファイルシステム内にない場合は、損傷したファイルシステム以外のディレクトリに移動し、ファイルシステムをマウント解除します。
# umount /mount-point |
次の手順では、必ず newfs -N オプションを使用してください。-N オプションを省略すると、新しい空のファイルシステムが作成されます。
newfs -N コマンドを使用して、スーパーブロックの値を表示します。
# newfs -N /dev/rdsk/device-name |
このコマンドの出力には、newfs コマンドによってファイルシステムが作成されたときに、スーパーブロックのコピーとして使用されることになったブロック番号が表示されます。カスタマイズされたファイルシステムを作成する方法については、カスタムファイルシステムパラメータを参照してください。
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 コマンドを実行した場合は、修復が行われる前に確認を求めるプロンプトが表示されます。このコマンドには、次の 4 つのオプションがあります。
コマンドとオプション |
説明 |
---|---|
fsck -m |
ファイルシステムがマウント可能かどうかのチェックを行う |
fsck -y |
すべての修復に対して yes の応答が指定されたものとして処理を行う |
fsck -n |
すべての修復に対して no の応答が指定されたものとして処理を行う |
fsck -o p |
確認を求めるプロンプトを表示することなく、ファイルシステムを修復し、想定される (軽微な) 不整合箇所をすべて修正するが、重大な問題が見つかると終了する |