ファイルシステムのチェックと修復: fsckコマンド
1. なぜファイルシステムをチェックすることが重要なのか？
Linuxのファイルシステムは、実はOSの中で最も「忙しい」スタッフの一人なんだよ。ファイルを保存したり、プログラムを開いたり、ただデータを読むときさえも働いているんだ。でも、想像してみて：一番大事な時にそのスタッフが疲れて気絶しちゃった（つまり：停電でシステムがシャットダウンした）。これがファイルテーブルの破損、データの損失、または他の面倒な問題につながるかもしれないんだ。
でも、何が起こり得るの？
- 突然の電源断 — デバイスが突然オフになって、データの書き込みが完了しなかった。
- ストレージのエラー — ハードディスクやSSDにはハードウェアの問題があり、ファイルシステムが損傷する可能性がある。
- ソフトウェアのエラー — ドライバーやシステムユーティリティにバグがある場合もあるよ。
こういう出来事の後、しばしばファイルシステムがダメージを受けて、システム自体が状態を確認するよう頼むことがあるよ。ここで頼りになるのが fsck、つまりFile System Checkだね。
2. fsckとは？それはどう動作するの？
ツールのアイデア
fsckは、ファイルシステムの整合性を確認し、見つかったエラーを修正する汎用ユーティリティだよ。医者みたいな感じで、テストを行って問題を見つけ、可能であれば"治療"するんだ。問題が深刻すぎる場合でも、少なくとも何が問題かを診断することができる。
いつfsckを使うの？
- 明らかなファイルの故障（例えば、突然"消えた"とき）。
- システムが起動せず、ファイルシステムのエラーを報告しているとき。
- 定期的な点検として、すべてが問題ないことを確認するため。
3. 基本構文 fsck
fsckを使うには、通常次のコマンドを使うよ:
fsck [オプション] <デバイス>
主なオプション:
-y— 修正を自動的に承認。毎回質問にyesを押すのが嫌な時に便利だよ。-n— チェックのみで修正なし (ドライラン)。何かを壊すのが怖い場合、状況を分析するのに便利。-t— ファイルシステムの種類を指定 (例:ext4,xfsなど)。-r— 対話モードを有効に (各修正を確認することになる)。
4. 実践: ファイルシステムの確認
簡単な確認から始めましょう。例えば、/dev/sdb1というデバイスがあり、それをチェックしたいとします。
ステップ1: 修正なしの確認
まず、変更を加えずにファイルシステムの状態を評価します:
fsck -n /dev/sdb1
コマンドを実行すると、問題が見つかった場合、そのリストが表示されます。以下は出力例です:
Inodes that were part of a corrupted orphan linked list found.
Filesystem errors detected. Run fsck to repair.
ステップ2: 自動修正
次に、エラー修正モードを有効にします:
fsck -y /dev/sdb1
fsckは検出されたすべてのエラーを修正しようとし、自動的にアクションを確認します。デバイスが大きい場合、少し時間がかかることがあります。
5. ファイルシステムが使用中の場合どうする？
fsckの起動時のエラー
すでにマウントされているパーティションでfsckを実行しようとすると、以下の警告が表示されます:
fsck: cannot check a mounted filesystem.
これは、マウントされたファイルシステムの検証がデータ破損を引き起こす可能性があるためです。この問題を解決する方法はいくつかあります。
- デバイスを読み取り専用モードでマウントします。
mount -o remount,ro /dev/sdb1
- LiveCDまたはLiveUSBを使用します。
既にアンマウントされたデバイスを確認するために、ブートディスクまたはUSBから起動してください。
- リカバリモードを使用します。
システムをリカバリモードで再起動します。通常、これは検証を安全に行える環境を提供します。
ルートファイルシステム/の検証の特性
ルートファイルシステムは特殊なケースです。なぜなら、システムによって積極的に使用されているからです。このようなパーティションでfsckを実行するには以下が必要です:
- 以下のコマンドを使用してシングルユーザーモードに移行します:
systemctl isolate rescue.target
- 手動で
fsckを実行します:
fsck -y /
6. よくあるエラーとその修正
壊れたinode
もしfsckが壊れたinode（ファイル情報を保持する構造体）について報告した場合、それらを削除するよう提案してくるよ。これは安全だから心配しないでね。壊れたinodeは現在のファイルと関連付けられていないから。
紛失したファイル
時々、fsckを実行した後、紛失したファイルがファイルシステムのルートにあるlost+foundディレクトリに入ることがあるよ。重要なデータを復元するために手動でそこを確認してみよう。
重要なアドバイス
チェックを実行する前に必ずバックアップを取ってね。
fsckは通常安全に動作するけど、修正の過程でデータが失われることがあるよ。マウントされたパーティションで
fsckを実行しないでね。 そうしちゃうとデータが壊れるかもしれないよ。最初の分析には
-nフラグを使おう。 エラーを自動的に修正するべきかどうか確信がない場合は、まずドライランから始めてみよう。
7. 例: エラーのシミュレーションと修正
- 仮想ディスクを作成し、そこにファイルシステムを作成します:
dd if=/dev/zero of=./disk.img bs=1M count=100
mkfs.ext4 ./disk.img
- ディスクをマウントします:
sudo mount ./disk.img /mnt/test/
- 破損をシミュレーションします:
sudo dd if=/dev/zero of=/mnt/test/randomfile bs=512 count=10
- ディスクをアンマウントして、チェックします:
sudo umount /mnt/test/
fsck ./disk.img
コマンドの出力に従い、エラーを修正してください。
ここまでで、ファイルシステムのチェックに自信を持ち、エラーを正しく修正し、障害を防ぐことができます。これから、ファイルシステム操作のための新しいツールを学んでいきますが、fsckは診断と修正のための信頼できるツールになりました。
GO TO FULL VERSION