壊れることのないファイルシステム（データ損失は許容可能）
この問題を中心に展開している既存のトピックがいくつかありますが、私が求めているものは少し異なります。組み込みLinuxにSDカードがあり、電力損失が発生します。ある時点でハードウェアを変更したり、適切に閉じたりすることができるかもしれません。しかし、今は、大騒ぎせずに電力損失に耐えるファイルシステムを見つけたいと思っています。データの損失は許容されます。現在書き込んでいるファイルよりも多くのファイルを失いたくないのですが、「マウントできません」、「この10分間fsckを待つ」、または「新しいファイルを作成できない」に直面するよりも、すべてを失いたいです。このiノードが原因でファイルに何かエラーが発生しました。プログラムは続けなければなりません！
私はこれを確実にするために多くの努力をしています。私は工業用グレードのコンポーネントを使用しています。ハードウェアウォッチドッグ、ソフトウェアウォッチドッグ、内部、外部、プログラムの初期化、デーモンがメモリ、ファイル記述子などを常にチェックしています。ウォッチドッグがウォッチドッグを監視しており、ウォッチドッグが他のウォッチドッグによって監視されています。 ...しかし、SDカードがマウントされて機能することを保証できないようです。
今の私の最善の策は、SDカードでJFSを使用し、インストールにfsckとfsck.jfsを含めることです。 （600kb以上を追加してRAMとフラッシュを食べます。これは悪いことです。）そして、起動するたびにfsckを実行します（起動時間が長くなる可能性があります。これはやや悪いです）。でも少し悲しいようです。
より良い方法やより良いファイルシステムを知っている人はいますか？
更新：e2fsprogs-libs（jfsutilsへの依存関係）は、私のディストリビューションでコンパイルするのが非常に難しいようです。 ZFSを調べます（ただし、ZFSは私のディストリビューションにネイティブではありません。そして、私が必要としないことをたくさん行っているようです）。
UPDATE2：システムとテストに関する詳細情報：SDカードストレージは、セカンダリのオプションのストレージです。 SDカードは2Gb-8Gb工業用グレードのmicroSDです。 SDカードは、mount-tコマンドを使用してrcを介してマウントされます。オプション「noatime」。「sync」ではありません。私のディストリビューションは、3.10カーネルと1.21ビジーボックスを備えたカスタムアナログデバイスフレーバーのuClinuxです。私のプライマリストレージは、jffs2を使用したspiフラッシュです。私はそれで問題があったことはありません。 fsck.jffs2が利用可能かどうかさえわかりません。一方、ナンドフラッシュ...しかし、それは別の話です。 SDカードの目的は、測定データを保存することです。 「モニター」プログラムは結果をファイルに追加し、戦略的な同期配置を備えています。ファイルが指定されたサイズを超えると、新しいファイルが作成されます。指定された数のファイルに達すると、最も古いファイルが削除されます。停電により現在の測定ファイルが失われた場合でも、問題はありません。ファイルは通常50-100kbで、1つの結果は通常1kbです。これは開発の初期段階にすぎません。何も修正されていません。組み込みシステムで非フラッシュファイルシステムを扱ったのはこれが初めてです。 （x86サーバーでext4を入手しました。）
私はvfatから始めました。デフォルトのファイルシステム。 （工場にはそれを選択する理由があるかもしれないと思いました。そして、物事がうまくいくなら、私はそれほど気にしません。）組み込みvfatデバイスで電力損失の問題を見たことがありません。ただし、WinCEでFATの問題が発生しました。しかし、私の「モニター」プログラムが100〜200ファイルに達すると、それ以上の作成を拒否しました。 FATには、ルートに特別なファイル制限の問題があり、サブディレクトリに少し大きい問題があるようです。 1つのディレクトリに500〜1000個のファイルを作成できる必要があります。したがって、vfatは機能しません。
それから私はext2に切り替えました。ただし、起動時にfsckを挿入しませんでした。 （私がそうしなければならないことを知りませんでした。）1日以内に、私の「モニター」プログラムは、「inodesomethingsomething」エラーのためにそれ以上のファイルを作成できませんでした。災害！
私の現在の解決策は、起動時に「e2fsck-y」を指定したext2です。これまでのところ、それは有望なようです。しかし、e2fsckと「起動時のfsck」の概念全体が私を悩ませています。 e2fsck自体は、私のプライマリフラッシュとRAMの350kb以上を費やしています。 （実行されていないとき。）これは、それが私の最大のプログラムであることを意味します。それはbusyboxよりも大きいです。それは私のカーネルにほぼ匹敵します。
私はext3を検討してきました。メタデータをジャーナルに記録しているので、害はありません。しかし、それがどれだけ役立つかについては疑問があります。私の小さなファイルと制御された同期で、私はカバーされるべきだと思いますか？順序付けられた書き込みシーケンスがあります。つまり、データもある程度ジャーナル化されています。ただし、これは非決定論的なラグにつながる可能性があります。これは私の状況では悪いことです。 （おそらく問題ではありません。）また、スケジュールされた同期機能もあります。例えば。 5秒ごとにコミットします。これは私自身の同期を妨げていると思います。書き込みが多すぎるとSDカードに悪影響を及ぼします。工業用のものですら。これを無効にする方法に関するドキュメントが見つかりません。そしてext3 still起動するたびにfsckを実行する必要があります！しかし、ext3はまだ可能性があります。
Ext4。 ext3のパフォーマンスの問題の多くを修正します。でも、パフォーマンスは本当に必要ありません。そして、私のディストリビューションにはmkfs.ext4とfsck.ext4が組み込まれていないようです。おそらくそれは問題ではありません。でもそうかもしれません。例えば。 e2progs-libs（jfsutilsへの依存関係）には多くのコンパイルの問題があるようです。
JFS、XFS、BRFSS。すべて私のカーネルでサポートされています。現在、ユーザースペースツールボックスには含まれていません。すべてがかなり大きく、複雑なシステムのようです。そして、それらはすべて起動時に「fsck」に相当するものを必要とするようですか？
独自のファイルシステムをスローすることも検討しました。常にファイルテーブルのコピーを2つ書き込みます。トラバースするときに、正しいCRCと最新のシーケンス番号を持つものを選択します。 2段階の書き込みシーケンスを作成します。一時的に割り当て、コミット時に修正します。 fsckは必要ありません。でも少しナイーブかもしれません。
UPDATE3：ところで、組み込みシステム（少なくともこれ）の性質は、それらが自律的で、無人で、手の届かないところにあり、何年も実行しなければならないということです。 may人間の相互作用を必要とするfsckのようなプログラムは、私をぞっとさせます。
ここでのストーリーには、少し矛盾があるか、少なくともあいまいさがあります。
「マウントできない」、「この10分間のfsckを待つ」に直面するよりも、まだすべてを失いたい
これは、実際には言わないが、これが実際に発生している問題であることを意味します。しかしその後：
e2fsprogs-libs（jfsutilsへの依存関係）は、私のディストリビューションでコンパイルするのが非常に難しいようです。
意味e2fsprogs-libsはe2fsprogsを提供するe2fsckの依存関係であるため、fsckはまったくありません。したがって、おそらくあなたはまだここで計画段階にあり、たとえばext4でシステムをテストしたことさえありませんが、代わりにJFSから始めるべきであるという結論に飛びつきましたか？特別な理由はありますか？
Raspberry Piエクスチェンジ（piのプライマリストレージもSDカードです）で、大多数（私を含む）が一度も経験したことがないにもかかわらず、かなりの数のユーザーがこの種の問題に非常に不満を感じているようです。すべて。最初は、システムをきれいにシャットダウンする必要があることを知らない人だと思っていましたが、説明するとわかりにくいことではなく、システムなのに報告する人もいます正しくシャットダウンされました。
停電に耐えられるようにするためにこれが必要だとすでに言っていますが（これは十分に公平です）、いくつかのpis、またはいくつかのSDカードがあることを意味するのでこれについて言及します、または両方の組み合わせで、プラグを抜いたとき、またはプラグを元に戻したときに定期的に発生するイベント（サージ？）が原因でファイルシステムが破損する傾向があります。私も見たことがありません-そしてありますたくさんの人が試してみるのに十分な時間でした-誰かがbtrfsやjfsなどに切り替えたという報告があれば、問題は解決しました。
これに関するもう1つの不思議なことは、人々がコードを引っ張っていても、定期的にファイルシステムが使用できなくなることはないはずです。確かに私はそれを実行しましたpiで何回も、通常のLinuxボックスで数百回ではないにしてもスコア（電源が切れた、システムが応答しなくなった、疲れ果てて怒っているなど）、マイナーを見ている間データの損失、ファイルシステムが破損して、簡単なfsckの後で使用できなくなるのを見たことがありません。
繰り返しになりますが、これらすべてのレポートが真実であると仮定すると（なぜ多くの人がそれについて嘘をつくのかわかりません）、単に完全にアンマウントしないだけでなく、もっと多くのことが起こっていますが、それはごく一部のユーザーにしか影響しないようですある種の一般的なハードウェアの欠陥。
Piでは、ブートスクリプトで-yを/forcefsckに書き込むので、次回のブート時に自動的に実行され、必要かどうかに関係なく、問題が修正されます。 700 Mhzシングルコアでは、最大4GBのデータを含む12GBファイルシステムの場合、これには最大10秒かかります。したがって、「10分」は、特に「これは書き込み用の小さなファイルシステムです！」とすでに言っているので、信じられないほど長い時間のように聞こえます。
定期的にsyncを呼び出すことも検討してください。
最後に、実際に遭遇した問題のより事実的で具体的な詳細と誇張を少なくして質問を更新する必要があります。それ以外の場合は、時期尚早のように見えます XY問題 これは、多くの経験と潜在的なアドバイスを持つ人々によってすぐにスキップされる可能性があります。
プログラムは続けなければなりません！
これは一般的な要件であり、安定したシステムを選択する場合はLinuxシステムが最適です。
あなたの努力も正しい方向に進んでいないようです。しかし、安定したシステムを得るために何ができるでしょうか？
最初のレベルでは、ファイルシステムを改善できます。
yournal_data_orderedで作成または変更する場合は、ext3/ext4ファイルシステムでtune2fsを使用します。JFSを使用して、チェックするときに--replay_journal_onlyを使用します。- Initscriptsで
FSCKFIX=yesを設定して、自動修復を有効にします。
これだけでは不十分な場合は、バグのあるディスクをマウントせずにシステムを起動できます。代わりに、バグのあるディスクを手動でチェックして修復するときに、新しいramdiskを作成します。これは、スクリプトによって自動化することもできます。
次のレベルでは、組み込みシステムを離れて、 高可用性 に関するいくつかのトピックを読む必要があります。