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 ファイルシステムを検査するときには、次の点を考慮してください。

fsck を使用して検査するファイルシステムは、非アクティブでなければなりません。ディスクにまだフラッシュされていないファイルシステムの変更がある場合、または fsck による検査の進行中にファイルシステムを変更した場合、ファイルシステムの破損とみなされることがあります。この場合、問題の報告内容に信頼性があるとは言えません。
fsck を使用して修復するファイルシステムは、非アクティブでなければなりません。ディスクにまだフラッシュされていないファイルシステムの変更がある場合、または fsck による修復の進行中にファイルシステムを変更した場合、ファイルシステムが破損したり、システムがクラッシュしたりすることがあります。
fsck を使用する前に、そのファイルシステムのマウントを解除します。これにより、ファイルシステムのデータ構造の整合性をできるだけ確保できます。ただし、ルート (/) ファイルシステム、/usr ファイルシステム、および /var ファイルシステムだけは、アクティブにします。これらのファイルシステムは、fsck を実行するためにマウントする必要があります。
ルート (/) ファイルシステム、 /usr ファイルシステム、および /var ファイルシステムを修復する必要がある場合には、可能であれば代替デバイスからシステムをブートすると、マウント解除されて非アクティブになります。

ルート (/) ファイルシステム、/usr ファイルシステム、または /var ファイルシステムに対して fsck を実行する手順については、「代替ブートデバイスから UFS ルート (/) ファイルシステム、/usr ファイルシステム、または /var ファイルシステムを検査する方法」を参照してください。

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

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

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

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

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

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

スーパーユーザーになるか、同等の役割を引き受けます。
ルート (/) ファイルシステムがミラー化されているシステムの場合のみ: ルート (/) ミラーを切り離したあと、代替デバイスからブートします。先にブートしてしまうと、ファイルシステムが破損するおそれがあります。
ルート (/) ミラーの切り離しについては、『Solaris Volume Manager 管理ガイド』の「サブミラーに関する作業」を参照してください。
検査の必要なルート (/) ファイルシステム、/usr ファイルシステム、または /var ファイルシステムのデバイス (/dev/dsk/c0t0d0s0 など) を特定します。
このデバイス名は、代替デバイスからブートしたあとで指定する必要があります。代替デバイスからブートしたあとでは、このデバイスの特定がより難しくなります。
ローカルの Solaris DVD やネットワークなどの代替デバイスから検査する必要があるルート (/) ファイルシステム、/usr ファイルシステム、または /var ファイルシステムのあるシステムを、シングルユーザーモードでブートします。
この場合、ファイルシステム上に動作は存在しません。
例:
```
# init 0
ok boot net -s
.
.
.
#
```
手順 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
.
.
.
```
報告された fsck エラーをすべて修正します。
1 つまたは複数の UFS ファイルシステムを対話式で検査しながら、エラーメッセージのプロンプトに応答する方法については、『Solaris のシステム管理 (上級編)』の第 20 章「UFS ファイルシステムの不整合解決 (手順)」を参照してください。
fsck コマンドを実行してもすべての問題を修復できない場合は、「fsck コマンドで修復できない UFS ファイルシステムの修正」を参照してください。
修復したファイルシステムをマウントして、lost+found ディレクトリにファイルが存在するかどうかを確認します。
fsck コマンドによって lost+found ディレクトリに入れられた各ファイルの名前は、その i ノード番号を使用して変更されます。可能であれば、ファイル名を変更し、ファイルが含まれるべきディレクトリに移動してください。grep コマンドを使用して各ファイル内の語句を探したり、file コマンドを使用してファイルタイプを識別してください。
どうしても特定できないファイルまたはディレクトリについては、 lost+found ディレクトリからそれらを削除して、不要な領域を解放してください。
システムをマルチユーザーモードに戻します。
```
# init 6
```
ルート (/) ファイルシステムがミラー化されているシステムの場合のみ: ルート (/) ミラーを再接続します。

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

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

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

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

スーパーユーザーになるか、同等の役割を引き受けます。
ローカルファイルシステムをマウント解除し、ファイルシステム上でほかの動作が存在しないようにします。
fsck コマンドの引数として、マウントポイントディレクトリや /dev/dsk/ device-name を指定します。整合性が失われている場合には、そのことを示すメッセージが表示されます。
例:
```
# umount /export/home
# fsck /dev/rdsk/c0t0d0s7
** /dev/dsk/c0t0d0s7
** Last Mounted on /export/home
.
.
.
```
報告された fsck エラーをすべて修正します。
1 つまたは複数の UFS ファイルシステムを対話式で検査しながら、エラーメッセージのプロンプトに応答する方法については、『Solaris のシステム管理 (上級編)』の第 20 章「UFS ファイルシステムの不整合解決 (手順)」を参照してください。
fsck コマンドを実行してもすべての問題を修復できない場合は、「fsck コマンドで修復できない UFS ファイルシステムの修正」を参照してください。
修復したファイルシステムをマウントして、 lost+found ディレクトリにファイルが存在するかどうかを確認します。
fsck コマンドによって lost+found ディレクトリに入れられた各ファイルの名前は、その i ノード番号を使用して変更されます。
lost+found ディレクトリに保存されているファイルの名前を変更して移動します。
可能であれば、ファイル名を変更し、ファイルが含まれるべきディレクトリに移動してください。grep コマンドを使用して各ファイル内の語句を探したり、file コマンドを使用してファイルタイプを識別してください。
どうしても特定できないファイルまたはディレクトリについては、 lost+found ディレクトリからそれらを削除して、不要な領域を解放してください。

例 17-1 ルート (/) 以外、または /usr 以外の UFS ファイルシステムの対話型検査

次の例は、/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 コマンドを対話式で実行した場合の処理のサブセットです。

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

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

スーパーユーザーになるか、同等の役割を引き受けます。
UFS ファイルシステムをマウント解除します。
```
# umount /mount-point
```
修復オプションを指定して UFS ファイルシステムを検査します。
```
# fsck -o p /dev/rdsk/device-name
```
fsck コマンドの引数として /mount-point または /dev/rdsk/device-name を使用すると、個々のファイルシステムを修復できます。

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

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

# fsck -o p /export/home

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

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

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

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

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

ファイルシステム全体の復元については、「UFS ファイルおよびファイルシステムのバックアップを復元する (タスクマップ)」を参照してください。

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

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

ナビゲーションリンクをスキップ
印刷ビューの終了
	Oracle Solaris の管理: デバイスとファイルシステム Oracle Solaris 10 1/13 Information Library (日本語)