3

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

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

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

4

5 に答える 5

3

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

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

于 2008-10-05T17:55:33.897 に答える
1

NANDフラッシュのYAFFS2パーティションにプレーンな古いsyslogdを使用していますが、うまく機能しているようです。メッセージがロガーに送信され、メッセージが表示された直後(<100ms)に電源が切断され、ログが破損しているようには見えません。

これは、すべてが設計、精神によって常に一貫していることを明示的に知っているのではなく、観察に基づいています。

于 2008-10-12T23:24:25.853 に答える
1

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

于 2008-10-05T18:50:30.853 に答える
0

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

このようにして、最初の書き込み中にクラッシュした場合でも、2 番目のコピーのすべてのデータ (その書き込みまで) はそのまま残ります。

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

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

于 2008-10-06T03:59:40.387 に答える
0

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

ログを内部に保存する必要がある場合は、人間が判読できる平文のファイルが組み込みデバイスに最適なオプションであることがわかりました。「書き込み/フラッシュ」サイクルは高速で、維持するためのツールは必要なく、リアルタイムで監視できます。ファイル サイズが問題になる場合は、書式設定されたテキストではなく整数でタイムスタンプを付けたり、数値の「イベント ID」を使用して各ログを省略したりできます (インスタンス固有のデータのみをテキストとして残します)。

于 2008-11-10T02:20:01.687 に答える