Red Hat Training

A Red Hat training course is available for RHEL 8

第13章 ファイルシステムの確認と修復

RHEL は、ファイルシステムの確認および修復が可能なファイルシステム管理ユーティリティーを提供します。このツールは、通常 fsck ツールと呼ばれることが多く、fsck は、ファイルシステムチェック を短くした名前になります。ほとんどの場合、このようなユーティリティーは、必要に応じてシステムの起動時に自動的に実行しますが、必要な場合は手動で呼び出すこともできます。

重要

ファイルシステムチェッカーは、ファイルシステム全体のメタデータの整合性のみを保証します。チェッカーは、ファイルシステムに含まれる実際のデータを認識しないため、データのリカバリーツールではありません。

13.1. ファイルシステムの確認が必要なシナリオ

以下のいずれかが発生した場合は、関連する fsck ツールを使用してシステムを確認できます。

  • システムが起動しない
  • 特定ディスクのファイルが破損する
  • 不整合によりファイルシステムがシャットダウンするか、読み取り専用に変更する
  • ファイルシステムのファイルにアクセスできない

ファイルシステムの不整合は、ハードウェアエラー、ストレージ管理エラー、ソフトウェアバグなどのさまざまな理由で発生する可能性があります。

重要

ファイルシステムの確認ツールは、ハードウェアの問題を修復できません。修復を正常に動作させるには、ファイルシステムが完全に読み取り可能かつ書き込み可能である必要があります。ハードウェアエラーが原因でファイルシステムが破損した場合は、まず dd(8) ユーティリティーなどを使用して、ファイルシステムを適切なディスクに移動する必要があります。

ジャーナリングファイルシステムの場合、システムの起動時に通常必要なのは、必要に応じてジャーナルを再生することだけで、これは通常非常に短い操作になります。

ただし、ジャーナリングファイルシステムであっても、ファイルシステムの不整合や破損が発生した場合は、ファイルシステムチェッカーを使用してファイルシステムを修復する必要があります。

重要

/etc/fstab の 6 番目のフィールドを 0 に設定すると、システムの起動時にファイルシステムの確認を無効にできます。ただし、Red Hat は、システムの起動時に fsck に問題がある場合 (非常に大きなファイルシステムやリモートファイルシステムなど) を除いて、無効にすることを推奨しません。

関連情報

  • man ページの fstab(5)
  • man ページの fsck(8)
  • man ページの dd(8)

13.2. fsck の実行による潜在的な悪影響

通常、ファイルシステムの確認および修復のツールを実行すると、検出された不整合の少なくとも一部が自動的に修復されることが期待できます。場合によっては、以下の問題が発生する場合があります。

  • inode やディレクトリーが大幅に損傷し、修復できない場合は、破棄される場合があります。
  • ファイルシステムが大きく変更する場合があります。

予期しない変更や、望ましくない変更が永続的に行われないようにするには、この手順にまとめられている予防手順を行ってください。

13.3. XFS のエラー処理メカニズム

本セクションでは、XFS がファイルシステム内のさまざまな種類のエラーを処理する方法を説明します。

不完全なアンマウント

ジャーナリングは、ファイルシステムで発生したメタデータの変更のトランザクション記録を保持します。

システムクラッシュ、電源障害、またはその他の不完全なアンマウントが発生した場合、XFS はジャーナル (ログとも呼ばれる) を使用してファイルシステムを復旧します。カーネルは XFS ファイルシステムをマウントするときにジャーナルの復旧を実行します。

破損

この文脈での 破損 は、次のような原因によるファイルシステムのエラーを意味します。

  • ハードウェア障害
  • ストレージファームウェア、デバイスドライバー、ソフトウェアスタック、またはファイルシステム自体のバグ
  • ファイルシステムの一部が、ファイルシステム外の何かにより上書きされる問題

XFS は、ファイルシステムまたはファイルシステムメタデータの破損を検出すると、ファイルシステムをシャットダウンして、システムログにインシデントを報告することがあります。/var ディレクトリーが置かれているファイルシステムで破損が発生すると、このログは再起動後に利用できなくなります。

例13.1 XFS の破損を報告するシステムログエントリー

# dmesg --notime | tail -15

XFS (loop0): Mounting V5 Filesystem
XFS (loop0): Metadata CRC error detected at xfs_agi_read_verify+0xcb/0xf0 [xfs], xfs_agi block 0x2
XFS (loop0): Unmount and run xfs_repair
XFS (loop0): First 128 bytes of corrupted metadata buffer:
00000000027b3b56: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000005f9abc7a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000005b0aef35: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000000da9d2ded: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000001e265b07: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000006a40df69: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000000b272907: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000000e484aac5: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
XFS (loop0): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x2 len 1 error 74
XFS (loop0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
XFS (loop0): Failed to read root inode 0x80, error 11

ユーザー空間ユーティリティーは通常、破損した XFS ファイルシステムにアクセスしようとすると Input/output error メッセージを報告します。破損したログを使用して XFS ファイルシステムをマウントすると、マウントに失敗し、次のエラーメッセージが表示されます。 

mount: /mount-point: mount(2) system call failed: Structure needs cleaning.

破損を修復するには、手動で xfs_repair ユーティリティーを使用する必要があります。

関連情報

  • man ページの xfs_repair(8) に、XFS 破損チェックの詳細なリストがあります。

13.4. xfs_repair で XFS ファイルシステムの確認

この手順では、xfs_repair ユーティリティーを使用して XFS ファイルシステムの読み取り専用の確認を実行します。破損を修復するには、手動で xfs_repair ユーティリティーを使用する必要があります。xfs_repair は、その他のファイルシステム修復ユーティリティーとは異なり、XFS ファイルシステムが正しくアンマウントされていなくても起動時には動作しません。不完全なアンマウントが発生した場合、XFS は単にマウント時にログを再生して、一貫したファイルシステムを確保します。xfs_repair は、最初にマウントし直さずに、ダーティーログがある XFS ファイルシステムを修復することはできません。

注記

xfsprogs パッケージには fsck.xfs バイナリーがありますが、これは、システムの起動時に fsck.file システムバイナリーを検索する initscripts を満たすためにのみ存在します。fsck.xfs は、すぐに終了コード 0 で終了します。

手順

  1. ファイルシステムをマウントおよびアンマウントしてログを再生します。 

    # mount file-system
# umount file-system
    注記

    マウントが structure needs cleaning (構造のクリーニングが必要) エラーで失敗した場合は、ログが破損しているため再生できません。ドライランは、結果として、より多くのディスク上の破損を検出して報告する必要があります。

  2. xfs_repair ユーティリティーを使用してドライランを実行し、ファイルシステムを確認します。エラーが表示され、ファイルシステムを変更せずに実行できるアクションが示されます。 

    # xfs_repair -n block-device

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

    # mount file-system

関連情報

  • man ページの xfs_repair(8)
  • man ページの xfs_metadump(8)

13.5. xfs_repair で XFS ファイルシステムの修復

この手順では、xfs_repair ユーティリティーを使用して破損した XFS ファイルシステムを修復します。

手順

  1. xfs_metadump ユーティリティーを使用して、診断またはテストの目的で、修復する前にメタデータイメージを作成します。修復前のファイルシステムメタデータイメージは、破損がソフトウェアのバグによるものであるかどうかのサポート調査に役立ちます。修復前のイメージに含まれる破損のパターンは、根本的な分析に役に立つ場合があります。

    • xfs_metadump デバッグツールを使用して、XFS ファイルシステムからファイルにメタデータをコピーします。サポートに大きな メタダンプ ファイルを送信する必要がある場合は、標準の圧縮ユーティリティーを使用して生成された メタダンプ ファイルを圧縮してファイルサイズを縮小できます。 

      # xfs_metadump block-device metadump-file

  2. ファイルシステムを再マウントしてログを再生します。 

    # mount file-system
# umount file-system

  3. アンマウントしたファイルシステムを修復するには、xfs_repair ユーティリティーを使用します。

    • マウントが成功した場合、追加のオプションは必要ありません。 

      # xfs_repair block-device

    • マウントが Structure needs cleaning エラーで失敗した場合は、ログが破損しているため再生できません。ログを消去するには、-L オプション (force log zeroing) を使用します。

      警告

      このコマンドを実行すると、クラッシュ時に進行中だったすべてのメタデータの更新が失われます。これにより、ファイルシステムに重大な損傷やデータ損失が生じる可能性があります。これは、ログを再生できない場合に最後の手段としてのみ使用してください。 

      # xfs_repair -L block-device

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

    # mount file-system

関連情報

  • man ページの xfs_repair(8)

13.6. ext2、ext3、および ext4 でエラー処理メカニズム

ext2、ext3、および ext4 のファイルシステムは、e2fsck ユーティリティーを使用して、ファイルシステムの確認と修復を実行します。ファイル名の fsck.ext2、fsck.ext3、および fsck.ext4 は、e2fsck ユーティリティーへのハードリンクです。これらのバイナリーは、システムの起動時に自動的に実行し、その動作は確認されるファイルシステムと、そのファイルシステムの状態によって異なります。

完全なファイルシステムの確認および修復は、メタデータジャーナリングファイルシステムではない ext2 や、ジャーナルのない ext4 ファイルシステムに対して呼び出されます。

メタデータジャーナリング機能のある ext3 ファイルシステムおよび ext4 ファイルシステムの場合、ジャーナルはユーザー空間で再生され、ユーティリティーは終了します。これは、ジャーナルの再生によりクラッシュ後のファイルシステムの整合性が確保されるためのデフォルト動作になります。

このファイルシステムで、マウント中にメタデータの不整合が生じると、その事実がファイルシステムのスーパーブロックに記録されます。e2fsck が、このようなエラーでファイルシステムがマークされていることを検出すると、e2fsck はジャーナル (がある場合) の再生後にフルチェックを実行します。

関連情報

  • man ページの fsck(8)
  • man ページの e2fsck(8)

13.7. e2fsck で ext2、ext3、または ext4 ファイルシステムの確認

この手順では、e2fsck ユーティリティーを使用して、ext2 ファイルシステム、ext3 ファイルシステム、または ext4 ファイルシステムを確認します。

手順

  1. ファイルシステムを再マウントしてログを再生します。 

    # mount file-system
# umount file-system

  2. ドライランを実行して、ファイルシステムを確認します。 

    # e2fsck -n block-device
    注記

    エラーが表示され、ファイルシステムを変更せずに実行できるアクションが示されます。整合性の確認後のフェーズでは、修復モードで実行していた場合に前のフェーズで修正されていた不整合が検出される可能性があるため、追加のエラーが出力される場合があります。

関連情報

  • man ページの e2image(8)
  • man ページの e2fsck(8)

13.8. e2fsck で ext2、ext3、または ext4 ファイルシステムの修復

この手順では、e2fsck ユーティリティーを使用して、破損した ext2、ext3、または ext 4 のファイルシステムを修復します。

手順

  1. サポート調査のためにファイルシステムイメージを保存します。修復前のファイルシステムメタデータイメージは、破損がソフトウェアのバグによるものであるかどうかのサポート調査に役立ちます。修復前のイメージに含まれる破損のパターンは、根本的な分析に役に立つ場合があります。

    注記

    ファイルシステムが大幅に損傷している場合は、メタデータイメージの作成に関連して問題が発生する可能性があります。

    • テスト目的でイメージを作成する場合は、-r オプションを指定して、ファイルシステム自体と同じサイズのスパースファイルを作成します。その後、e2fsck は作成されたファイルで直接操作できます。 

      # e2image -r block-device image-file

    • 診断用にアーカイブまたは提供するイメージを作成する場合は、-Q オプションを使用して、転送に適したよりコンパクトなファイル形式を作成します。 

      # e2image -Q block-device image-file

  2. ファイルシステムを再マウントしてログを再生します。 

    # mount file-system
# umount file-system

  3. ファイルシステムを自動的に修復します。ユーザーの介入が必要な場合は、e2fsck が出力の未修正の問題を示し、このステータスを終了コードに反映させます。 

    # e2fsck -p block-device

    関連情報

    • man ページの e2image(8)
    • man ページの e2fsck(8)
このページには機械翻訳が使用されている場合があります (詳細はこちら)。