私たちは BBB ベースのカスタム ボードを持っています。これは 256MB の RAM と 4GB の eMMC を備えています。私たちは Linux-3.12 を使用しており、eMMC には ext4 パーティションがあります。
私は定期的に実行され、ファイル システム エラーをチェックするスクリプトを作成しています。パーティションがマウントされていない場合は、e2fsck を使用してエラーを修正しようとしています。
最初は、e2fsck -n /dev/mmcblk0pN (N is partition number)ファイル システム パーティションのエラーをチェックするために使用していました。
ただし、パーティションがマウントされ、パーティション上にファイルが作成されているときに、上記のコマンドが間違った結果を返すようになりました。
ここで、ファイル システム エラーをチェックする別の方法が必要になりました。1
つのオプションは、tune2fs -lそのパーティションでFilesystem stateフィールドをチェックするコマンドを使用することです。
このフィールドがファイルシステムのエラーをチェックするのに信頼できるかどうかはわかりません。また、このフィールドにはどのような値があるのでしょうか。その値は確認しましたが、cleanマニュアルページから詳細情報は得られません。clean with errorsnot clean
それで、tune2fs -l /dev/mmcblk0pN | grep “Filesystem state” | grep “error”ファイル システム エラーを検出することは信頼できるのでしょうか? パーティション内のファイル システム エラーをチェックするための他のより良いオプションはありますか?
何か提案/指針/情報はありますか?
答え1
「Tune2fs -l」は、カーネルが実行中にファイル システムの破損の問題を検出したかどうかを示します。たとえば、ext4 にファイルを削除するように指示し、ext4 がそのファイル内の一部のブロックがすでに割り当て解除済みとしてマークされていることを検出した場合、割り当てビットマップが破損していることを意味します。割り当てビットマップは、ext4 がそれを検出した時点ですでに破損していたことに注意してください。実際、数日または数週間破損していた可能性があり、新しいファイルを書き込んでいた場合、ext4 が古いファイルで使用されていたブロックを新しいファイルに割り当てた可能性があり、その結果、ユーザーがデータを失った可能性があります。
ファイル システムが一貫しているか、またはある程度破損している可能性があるかを確実に判断する唯一の方法は、ファイル システムに対して e2fsck を実行することです。これを行うには、ファイル システムをアンマウントするか、読み取り専用スナップショットを作成する必要があります。(LVM を使用している場合は、読み取り専用スナップショットを作成し、読み取り専用スナップショットをチェックして、ファイル システムが破損していることが判明した場合は、システムを再起動して e2fsck でファイル システムを修復するか、システム管理者に電子メールを送信してファイル システムを修復するためのダウンタイムをスケジュールすることができます。)
とはいえ、ファイル システムが破損した場合、最も一般的なケースとしてはハードウェアの問題が原因と考えられます。カーネルのバグが原因である可能性もありますが、アップストリームだけでなく安定したカーネルでも定期的に回帰テストを実行しており、ファイルシステム破損の問題は長い間発生していません。デバイス ドライバーにメモリ破損のバグがある可能性があり、(a) デバイス ドライバーがアップストリームではなく、ハードウェア ベンダーが適切な品質管理を行っていないか、(b) バグがアップストリームで修正され、最新の安定したカーネルにプッシュされているが、デバイス カーネルが安定したカーネル シリーズからの更新を取得していないかのいずれかです。
カーネルが明らかに間違ったことに遭遇したためにファイル システムが破損していることが判明したかどうかを調べたい場合は、dmesg や /var/log/messages をスクレイピングするだけでは十分ではありません。/sys/fs/ext4//first_error_time ファイルを読み込んでみることもできます。このファイルに 0 以外の値が含まれている場合は、カーネルによってファイル システムの破損が検出された時刻 (Unix エポックを使用) がわかります。このディレクトリの errors_count ファイルには、検出されたファイル システムの破損の数が表示されます (ただし、システムが同じ問題に何度も遭遇しているだけである可能性もあります)。また、カーネルによって検出されたファイル システム エラーをシステムがどのように処理しているかをテストしたい場合は、trigger_fs_error ファイルに文字列を書き込んでみてください --- たとえば、echo "test error" > /sys/fs/ext4/sda1/trigger_fs_error"
最後に、tune2fs で設定できるエラー動作ノブを確認してください。ファイル システムの破損の問題が検出された後に、さらに損害が発生しないように確実にしたい場合は、問題が見つかったときにファイル システムを読み取り専用で再マウントするように構成するか、再起動を強制して、ブート シーケンス中に e2fsck を実行し、(さらに多くの) ユーザー データが破損または失われる前に問題を修正することができます。