自動化されたext3ルートファイルシステムは正確に何をチェックしますか？
最近、組み込みLinuxシステムを実行しているext3フォーマットのコンパクトフラッシュカードで問題（不良ブロック）が発生しました。起動時にルートファイルシステムのチェックを開始しましたが、通常よりもかなり時間がかかったため、ハングしたようです。その後、カードを別のPCに接続したところ、不良ブロックが検出されました。十分長く待っていたら、最初のルートファイルシステムチェックで修復されたブロックも見つかったのではないかと思います。それを見つけるために、tune2fsとe2fsckのマニュアルページを確認しましたが、質問に対する答えが見つかりませんでした。
これらの自動化されたルートファイルシステムチェックで実行されるチェック/修復に影響を与えることはできますか？はいの場合、どうすれば設定できますか？
構成できない場合：正確にチェックまたは修復されるもの、デフォルト設定、自動チェックに使用されるフラグは何ですか？
最初のルートファイルシステムチェックで修復されたブロックが見つかった場合
ファイルシステムでジャーナリングが有効になっておらず、システムがクラッシュした場合にのみ、OSはext3で自動の完全なfsckをトリガーしますまたは再マウント制限に達しました。不良ブロックの書き込みまたは読み取りを試みた場合は検出されますが、自動fsckはトリガーされませんでした。構成方法に応じて、ディスクを読み取り専用で再マウントするか、カーネルパニックをスローします。
ジャーナリング用に設定されていると仮定すると、マウントで実行されるテストでは、ロールフォワードする必要のあるジャーナル操作のみがチェックされます。
Tune2fsをチェックしました
-i、-C、および-cフラグが何をするかを見ましたか？ （これらは将来の再起動時にのみfsckをトリガーすることに注意してください-実行中のシステムでルートfsckをスケジュールすることはできません）。
CFテクノロジーは、他のフォーマットに比べてかなり長くなり、比較的高価になっています。このカードは何歳で、保存する価値があるのかという疑問が生じています。そのようなデバイスのオペレーティングシステムを実行することはかなり可能ですが、それらは実際にはこの目的のために意図されていません-SATA接続のNANDフラッシュドライブは一般的になりつつありますが、SDカードなどよりもはるかに高価な理由はそれがたくさん含まれているためですストレージを管理し、不良ブロックを処理するためのスマートの。
残念ながら、IDE/SCSI/USBを介して接続された基本的な書き込み制限のあるストレージデバイスを管理できるファイルシステムはありません（JFFS2は、基盤となるストレージへの直接アクセスを利用します-つまり、PCIeバスに接続されたデバイス）。
CFデバイスが通常のディスクのように動作することを期待することは確かに非常に広告のアイデアです-子犬を見てください-それはディスクへの書き込みの量を減らすためにオーバーレイでいくつかの非常に巧妙なことをしますが、多くのことを行うことは可能です書き込みの頻度を減らすためにすべてのファイルシステムを調整する-ラップトップ上のLinuxを調整してI/Oを減らすための推奨事項を確認してください。