私のデバイスには、モジュールディスクまたはコンパクトフラッシュストレージを使用するTinyCore（3.6）Linuxディストリビューションがあります。
ファイルシステムはext2です。
私はこのデバイスにLAMPスタックを持ち、400を超えるテーブル（myisam）を持つMySQLデータベースを使用しています。書き込みは15分ごとに体系的に行われます。
このテーブルは、設定要件に応じてWebアプリケーションによって生成されます。
電源が不足すると、デバイスが突然シャットダウンする可能性があります。
updateMySQLが特定の書き込み操作（たとえば、、、、delete）を実行すると、insert一部のデータファイルとインデックスファイルが破損する可能性があります。
もちろん大きな問題ではありませんが、repair table手術をすることも悪くありません。残念ながら、一部のデータが失われたにもかかわらず、テーブルが回復され、アプリケーションが実行を続けることができました（私の場合は許可されています）。
問題は、通常、突然のシャットダウンが発生した場合、複数のmysqlテーブルファイル（FRM、MYI、またはMYD）が「入力/出力エラー」状態にあり、MySQLフロントエンドでこれらのファイルに対して「ストレージエンジンエラー5」（I / Oエラー）を報告するということです。テーブル。データベースを使用するアプリケーションは明らかに正しく実行されません。
同様のイベント（ある程度避けられないと思う）を防ぐのではなく、上記のシナリオから派生したファイルI / Oエラーの状況を回復するための正確で自動的に回復する方法を考えたいと思います。
どんなアイデアがありますか？
編集する： 残念ながらext3に切り替えることはできず、ext2に固執する必要があります。また、ext3はソリッドステートメモリの書き込み周期に重大な影響を与えるためです。
ベストアンサー1
CFを使うと使えないと思うDMマルチパスまたは、他の高可用性機能を使用している場合は、寿命を延ばすには、少なくとも「noatime」オプションを使用してそのファイルシステムをマウントする必要があります（ユーザー固有のスクリプトはatimeなどに依存しません）。
それ以外は最も強力なプラットフォームのように聞こえません。