在我正在開發的Linux嵌入式應用程序中，需要記錄一些不時發生的事件。這些記錄保存在MTD閃存設備上，寫入後無需更改或執行高效搜索，但需要讀取訪問權限才能將數據顯示給用戶。 一個很大的問題是，如果沒有正確的關機順序，電源可能隨時消失。 這些事件發生的頻率可能非常緩慢（天/星期），但其中幾個會立即發生。 要爲每個事件保存的數據是強類型的：日期，時間，幾個簡短的文本字符串和幾個整數。黑盒類型數據記錄
目前我繼承了基於jffs2和SQLite的解決方案，它遠非最佳，因爲DB文件有時會損壞。發生這種情況時，整個文件變得不可讀，並且無法理解它是由jffs2中的錯誤還是SQLite中的錯誤引起的，或者閃存扇區是壞的，還是在錯誤的時間斷電。
是否有一個庫或文件系統/庫的組合可以更好地幫助我解決這類問題？或者我應該只使用CSV格式的文本文件？
我們使用老式的syslogd對NAND閃存一個YAFFS2分區，這似乎很好地工作：當郵件被髮送到記錄器和電源被移除後立即（< 100毫秒）的消息是存在的，從來沒有出現在日誌腐敗。
這是建立在觀察的基礎上，而不是我明確地知道每件事總是會在設計和思維上保持一致。
我並不熟悉嵌入式系統，但我認爲CSV可能是最好的。它基本上不會被損壞，或者如果它確實如此，那麼您可以輕鬆地看到錯誤並手動修復它（新行或僅刪除一行）。我一直在努力從嵌入式系統接收數據，他們有很多腐敗問題（部分在系統上，部分在電話線路傳輸過程中）。如果它是CSV格式的格式，這將非常有用，因此我們可以找到錯誤並刪除或修復它們而不是破壞整個數據集。
如果您不需要在系統內搜索，那麼CSV就可以完美工作。
兩個csv /文本文件。每次系統重新啓動時啓動一個新對。將每個事件寫入第一個文件，刷新文件以存儲，將記錄寫入第二個文件，然後再次刷新。
這樣，如果您在第一次寫入期間崩潰，則第二個副本中的所有數據（直到寫入）仍將存在。
確保flush是一個完整的文件系統刷新，而不僅僅是clib緩衝區刷新。
也可能將文件放在單獨的文件系統上。在你需要的東西之前預留空間也可以幫助加快這個過程。
有哪些設施可供您使用？最好的選擇是通過登錄到外部資源，例如通過系統日誌，SNMP，原始套接字或串行端口登錄到。這可以保護您的設備本身的日誌不會令人不快。
如果您需要在內部存儲日誌，我發現明文，人類可讀文件是嵌入式設備中的最佳選擇。 「寫入/刷新」週期很快，不需要任何工具來維護它們，並且可以實時監控它們。如果文件大小有問題，則可以使用整數而不是格式化文本的時間戳，並且可以使用數字「事件ID」來縮寫每個日誌（僅將實例特定的數據保留爲文本）。