test

Solaris のシステム管理 (デバイスとファイルシステム)

第 21 章 UFS ファイルシステムの整合性検査 (手順)

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

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

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

Solaris 10 6/06 リリースの fsck に関する最新情報については、「UFS ファイルシステムユーティリティー (fsck、mkfs、および newfs) の拡張機能」を参照してください。

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

この章で取り上げる UFS ファイルシステム構造のバックグラウンド情報については、第 22 章UFS ファイルシステム (参照情報)を参照してください。

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

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

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

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

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

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

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

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

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

次の表に、状態フラグが取り得る値とその説明を示します。

表 21–1 ファイルシステムの状態フラグの値

状態フラグの値 

説明 

FSACTIVE

このファイルシステムがマウント済みであり、メモリー内のデータが変更されたことを示します。この状態フラグを持つマウント済みファイルシステムでは、システムの電源が切断されると、ユーザーデータまたはメタデータが失われます。 

FSBAD

このファイルシステムに不整合なファイルシステムデータが含まれていることを示します。 

FSCLEAN

このファイルシステムが正常にマウント解除されており、破損していないことを示します。 

FSLOG

このファイルシステムのロギングが有効になっていることを示します。このフラグが設定されたファイルシステムは、マウントされている場合も、マウント解除されている場合もあります。ロギングが有効になっているファイルシステムに設定できるフラグは、FSLOG、FSBAD のいずれかです。ロギングが無効になっているファイルシステムに設定できるフラグは、FSACTIVE、 FSSTABLE、FSCLEAN のいずれかです。

FSSTABLE

このファイルシステムがマウント済みであり、アイドル状態であることを示します。この状態フラグを持つマウント済みファイルシステムでは、システムの電源が切断されても、ユーザーデータやメタデータが失われることはありません。 

fsck コマンドで検査して修復される内容

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

UFS ファイルシステムの不整合が発生する理由

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

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

別の目的にバッファーが必要になったり、カーネルが 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 ノードを検索します。fsck コマンドでは、どの i ノードでエラーが発生しているか、正確に判断することはできません。このため、保持する i ノードと消去する 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 3a - Check Connectivity
** Phase 3b - Verify Shadows/ACLs
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cylinder 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 コマンドを実行して UFS ファイルシステムを検査するときには、次の点を考慮してください。

Procedure代替ブートデバイスからルート (/) ファイルシステム、/usr ファイルシステム、または /var ファイルシステムを検査する方法

Solaris 10 6/06 リリースの fsck に関する最新情報については、「UFS ファイルシステムユーティリティー (fsck、mkfs、および newfs) の拡張機能」を参照してください。次のメッセージが表示される場合は、fsck を再実行する必要はありません。


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

ただし、このメッセージのあとに fsck を再実行してもファイルシステムは損傷しません。このメッセージは、fsck の修正処置に関する情報を示すだけのものです。

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

不正なスーパーブロックの復元については、「不正なスーパーブロックを復元する方法 (Solaris 10 6/06 リリース)」または 「不正なスーパーブロックを復元する方法 (Solaris 8、9、および 10 リリース)」を参照してください。

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

  2. ルート (/) ファイルシステムがミラー化されているシステムの場合のみ: ルート (/) ミラーを切り離したあと、代替デバイスからブートします。先にブートしてしまうと、ファイルシステムが破損するおそれがあります。

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

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

    このデバイス名は、代替デバイスからブートしたあとで指定する必要があります。代替デバイスからブートしたあとでは、このデバイスの特定がより難しくなります。

  4. ローカルの Solaris DVD やネットワークなどの代替デバイスから検査する必要があるルート (/) ファイルシステム、/usr ファイルシステム、または /var ファイルシステムのあるシステムを、シングルユーザーモードでブートします。

    この場合、ファイルシステム上に動作は存在しません。

    次に例を示します。


    # init 0
ok boot net -s
.
.
.
#

  5. 手順 3 で特定したルート (/) ファイルシステム、 /usr ファイルシステム、または /var ファイルシステムが含まれるデバイスを検査します。

    検査または修復するファイルシステムのハードウェアが変更されている場合には、そのデバイス名も変更されている可能性があります。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 のシステム管理 (上級編)』の第 20 章「UFS ファイルシステムの不整合解決 (手順)」を参照してください。

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

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

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

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

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


    # init 6

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

Procedureルート (/)、/usr、または /var 以外のファイルシステムを検査する方法

Solaris 10 6/06 リリースの fsck に関する最新情報については、「UFS ファイルシステムユーティリティー (fsck、mkfs、および newfs) の拡張機能」を参照してください。次のメッセージが表示される場合は、fsck を再実行する必要はありません。


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

ただし、このメッセージのあとに fsck を再実行してもファイルシステムは損傷しません。このメッセージは、fsck の修正処置に関する情報を示すだけのものです。

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

不正なスーパーブロックの復元については、「不正なスーパーブロックを復元する方法 (Solaris 10 6/06 リリース)」または 「不正なスーパーブロックを復元する方法 (Solaris 8、9、および 10 リリース)」を参照してください。

  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 のシステム管理 (上級編)』の第 20 章「UFS ファイルシステムの不整合解決 (手順)」を参照してください。

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

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

    fsck コマンドによって lost+found ディレクトリに入れられた各ファイルの名前は、その i ノード番号を使用して変更されます。

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

    可能であれば、ファイル名を変更し、ファイルが含まれるべきディレクトリに移動してください。grep コマンドを使用して各ファイル内の語句を探したり、file コマンドを使用してファイルタイプを識別してください。

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

例 21–1 ルート (/) 以外、または /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)
 
***** FILE SYSTEM WAS MODIFIED *****
#

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

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

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

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

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

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

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


    # umount /mount-point

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


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

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

例 21–2 UFS ファイルシステムを修復する

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


# fsck -o p /export/home

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

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

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

それでも fsck コマンドでファイルシステムを修復できない場合は、ff、clri、および ncheck コマンドを使用し、間違いを特定して修正します。これらのコマンドの使用方法については、次の情報を参照してください。

最終的には、ファイルシステムを作成し直し、その内容をバックアップメディアから復元せざるをえない場合があります。

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

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

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

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

ファイルシステムのスーパーブロック内のデータが破壊された場合は、復元しなければなりません。スーパーブロックが不正なときには、fsck コマンド からメッセージが表示されます。さいわい、スーパーブロックのコピーがファイルシステム内に格納されています。

fsck -o b コマンドを使用すると、スーパーブロックをいずれかのコピーと置き換えることができます。または fsck のバックアップスーパーブロックの自動検索機能を使用します。この機能は Solaris 10 6/06 リリースの新機能です。この機能の詳細は、「バックアップスーパーブロックの自動検索」を参照してください。

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

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

Procedure不正なスーパーブロックを復元する方法 (Solaris 10 6/06 リリース)

これは、Solaris 10 6/06 リリースの新しい手順です。ファイルシステムに不正なスーパーブロックがある場合は、次のメッセージに示すように fsck によって自動的に代替のスーパーブロックが計算されます。


BAD SUPERBLOCK AT ...

LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? 
LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS?
注意 – 注意 –

損傷したスーパーブロックが含まれるファイルシステムが、ntrack や nsect などの newfs または mkfs のカスタマイズされたパラメータを使用して作成されている場合、修復処理のために fsck で自動的に計算されたスーパーブロックがファイルシステムを損傷させる可能性があります。

カスタマイズされたパラメータを使用して作成されたファイルシステムで、ファイルシステムに不正なスーパーブロックが含まれている場合、fsck は、fsck セッションを取り消すための次のようなプロンプトを表示します。


CANCEL FILESYSTEM CHECK?

ファイルシステムがカスタマイズされたパラメータを使用して作成されている場合またはこのシステム上での fsck の実行に関する他の心配がある場合は、fsck セッションの取り消しが適切な応答です。

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

  2. 不正なスーパーブロックがあると思われるファイルシステムを検査します。


    # fsck /dev/rdsk/c0t1d0s0

** /dev/rdsk/c0t1d0s0

BAD SUPERBLOCK at ...

  3. ファイルシステムの作成方法を特定し、次のいずれかを選択します。

    • ファイルシステムが newfs コマンドを使用して作成された。

      • fsck がすべてのスーパーブロックが破損していることを報告し、汎用のスーパーブロックを使用する必要があります。下の例で説明するように、fsck プロンプトに応答します。

        注意 – 注意 –

        カスタマイズされたパラメータを使用してファイルシステムが作成されている場合はこのオプションを使用しないでください。このオプションは最後の手段として使用してください。バックアップコピーからファイルシステムを復元する準備をします。


        # fsck /dev/dsk/c1t2d0s0
** /dev/rdsk/c1t2d0s0
BAD SUPERBLOCK AT BLOCK 16: BLOCK SIZE LARGER THAN MAXIMUM SUPPORTED

LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? no


LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS? yes

SEARCH FOR ALTERNATE SUPERBLOCKS FAILED.

USE GENERIC SUPERBLOCK FROM MKFS? no


USE GENERIC SUPERBLOCK FROM NEWFS? yes

CALCULATED GENERIC SUPERBLOCK WITH NEWFS
If filesystem was created with manually-specified geometry, using
auto-discovered superblock may result in irrecoverable damage to
filesystem and user data.

CANCEL FILESYSTEM CHECK? no

** Last Mounted on
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3a - Check Connectivity
** Phase 3b - Verify Shadows/ACLs
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cylinder Groups
CORRECT GLOBAL SUMMARY
SALVAGE? y


UPDATE STANDARD SUPERBLOCK? y

81 files, 3609 used, 244678 free (6 frags, 30584 blocks, 0.0% fragmentation)

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

      • fsck が次のようなメッセージを表示し、代替のスーパーブロックが見つかったことを報告します。


        FOUND ALTERNATE SUPERBLOCK 32 WITH NEWFS

        この fsck のシナリオでは、「バックアップスーパーブロックの自動検索」 に示すようにプロンプトに従います。

    • ファイルシステムが mkfs コマンドを使用して作成された。

      • fsck がすべてのスーパーブロックが破損していることを報告し、汎用のスーパーブロックを使用する必要があります。下の例で説明するように、fsck プロンプトに応答します。

        注意 – 注意 –

        カスタマイズされたパラメータを使用してファイルシステムが作成されている場合はこのオプションを使用しないでください。このオプションは最後の手段として使用してください。バックアップコピーからファイルシステムを復元する準備をします。


        # fsck /dev/dsk/c1t2d0s0
** /dev/rdsk/c1t2d0s0
BAD SUPERBLOCK AT BLOCK 16: BLOCK SIZE LARGER THAN MAXIMUM SUPPORTED

LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? yes


LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS? no

SEARCH FOR ALTERNATE SUPERBLOCKS FAILED.

USE GENERIC SUPERBLOCK FROM MKFS? yes

CALCULATED GENERIC SUPERBLOCK WITH MKFS
If filesystem was created with manually-specified geometry, using
auto-discovered superblock may result in irrecoverable damage to
filesystem and user data.

CANCEL FILESYSTEM CHECK? no

** Last Mounted on
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3a - Check Connectivity
** Phase 3b - Verify Shadows/ACLs
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cylinder Groups
CORRECT GLOBAL SUMMARY
SALVAGE? y


UPDATE STANDARD SUPERBLOCK? y

81 files, 3609 used, 243605 free (117 frags, 30436 blocks, 0.0% fragmentation)

      • fsck が次のようなメッセージを表示し、代替のスーパーブロックが見つかったことを報告します。


        FOUND ALTERNATE SUPERBLOCK 32 WITH MKFS

        この fsck のシナリオでは、「バックアップスーパーブロックの自動検索」 に示すようにプロンプトに従います。

  4. プロンプトに応答し、スーパーブロックを復元します。

    次のメッセージが表示される場合は、fsck を再実行する必要はありません。


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

    ただし、このメッセージのあとに fsck を再実行してもファイルシステムは損傷しません。このメッセージは、fsck の修正処置に関する情報を示すだけのものです。

Procedure不正なスーパーブロックを復元する方法 (Solaris 8、9、および 10 リリース)

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

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

    • ルート (/) ファイルシステム、/usr ファイルシステム、または /var ファイルシステムに不正なスーパーブロックが存在する場合、ネットワークまたはローカルに接続された Solaris DVD からブートします。

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


      ok boot cdrom -s

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


      ok boot net -s

      システムを停止する必要がある場合は、『Solaris のシステム管理 (基本編)』の第 12 章「Oracle Solaris システムのブート (手順)」または『Solaris のシステム管理 (基本編)』の「GRUB を使用して x86 システムをブートする (作業マップ)」を参照してください。

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


      # umount /mount-point
      注意 – 注意 –

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

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


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

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

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


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

    fsck コマンドは、指定された代替スーパーブロックを使用して、一次スーパーブロックを復元します。代替ブロックとしては、常に 32 を使用できます。または、newfs -N コマンドの実行結果として出力される任意の代替ブロックを使用します。

例 21–3 不正なスーパーブロックの復元 (Solaris 8、9、および 10 リリース)

次の例は、スーパーブロックのコピー 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)

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

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

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

コマンドとオプション 

説明 

fsck -m

ファイルシステムがマウント可能かどうかの検査を行います 

fsck -y

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

fsck -n

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

fsck -o p

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