ブラックボックスタイプのデータロギング

Question

開発中のLinux組み込みアプリケーションでは、時々発生するいくつかのイベントを記録する必要があります。これらのレコードはMTDフラッシュデバイスに保存され、一度書き込まれると、それらを変更したり、効率的な検索を行う必要はありませんが、データをユーザーに表示するには読み取りアクセスが必要です。 大きな問題は、適切なシャットダウンシーケンスを行わなくても、いつでも電力が失われる可能性があることです。 これらのイベントが発生する頻度は非常に遅い可能性があります（日/週）が、それらのいくつかは一度に発生します。 イベントごとに保存されるデータは、日付、時刻、短いテキスト文字列、およびいくつかの整数で厳密に入力されます。

現在、jffs2とSQLiteに基づくソリューションを継承しましたが、DBファイルが破損することがあるため、最適とは言えません。これが発生すると、ファイル全体が読み取り不能になり、jffs2、SQLiteのバグが原因か、フラッシュセクターが不良であったか、電源が間違ったタイミングで切断されたかを理解する方法がありません。

この種の問題の解決に役立つライブラリーまたはファイルシステム/ライブラリーの組み合わせはありますか？または、CSVのような形式のテキストファイルを使用する必要がありますか？

Answer 1

NANDフラッシュのYAFFS2パーティションに単純な古いsyslogdを使用していますが、うまく機能しているように見えます：メッセージがロガーに送信され、すぐに（<！> lt; 100ms）メッセージがあり、ログが破損しているようには見えません。

これは、設計上、すべてが常に一貫していることを明確に認識しているのではなく、観察に基づいている、心。

Answer 2

私は組み込みシステムの専門家ではありませんが、CSVがおそらく最善だと思います。基本的に破損することはありません。破損した場合は、簡単にエラーを確認して手動で修正できます（新しい行または単に行を削除する）。私は、組み込みシステムからデータを受信することに取り組んでいます。組み込みシステムには、多くの破損問題があります（一部はシステム上で、一部は電話回線転送中）。データセット全体を破損するのではなく、エラーを見つけて削除または修正できるように、CSVタイプの形式であれば非常に役立ちます。

システム内で検索する必要がない場合、CSVは完全に機能します。

Answer 3

この目的のために正確に設計された多くの組み込みファイルシステム（ファット互換ではありません）があります。一度も使用したことはありませんが、こちらのGoogleから何かを提案することはできません。 GPLベースの何かがあるかもしれませんが、もっと掘り下げることができると確信しています。異なるファイルシステムの比較は、こちら

です。

Answer 4

csv /テキストファイル2つ。システムが再起動するたびに新しいペアを開始します。各イベントを最初のファイルに書き込み、保存するファイルをフラッシュし、レコードを2番目のファイルに書き込み、再度フラッシュします。

この方法では、最初の書き込み中にクラッシュした場合、2番目のコピー（その書き込みまで）のすべてのデータがそこに残ります。

フラッシュが、clibバッファーフラッシュだけでなく、完全なファイルシステムフラッシュであることを確認します。

ファイルを別のファイルシステムに配置することもできます。必要なスペースよりも先にスペースを確保しておくと、プロセスをスピードアップできます。

Answer 5

利用可能な施設は何ですか？多くの場合、最良のオプションは、syslog、SNMP、rawソケット、シリアルポートなどを使用して外部リソースにログを記録することです。これにより、デバイス自体の不愉快さからログが保護されます。

ログを内部に保存する必要がある場合、プレーンテキストの人間が読めるファイルが組み込みデバイスの最適なオプションであることがわかりました。 <！> quot; write / flush <！> quot;サイクルは高速であり、それらを維持するためのツールは不要であり、リアルタイムで監視できます。ファイルサイズに問題がある場合は、書式設定されたテキストではなく整数でタイムスタンプを付けることができます。また、数値<！> quot; Event ID <！> quot;を使用できます。各ログを短縮します（インスタンス固有のデータのみをテキストとして残します）。