Enregistrement de données de type Blackbox

Question

Dans une application Linux intégrée que je développe, il est nécessaire d’enregistrer certains événements qui se produisent de temps en temps. Ces enregistrements sont sauvegardés sur un périphérique flash MTD et une fois écrits, il n’est pas nécessaire de les modifier ni de faire des recherches efficaces, mais un accès en lecture est nécessaire pour afficher les données à l’utilisateur. Un gros problème est que l’alimentation peut s’extraire à tout moment, sans une séquence d’arrêt adéquate. La fréquence de ces événements peut être très lente (jours / semaines), mais plusieurs d'entre eux se produiront en même temps. Les données à enregistrer pour chaque événement sont fortement typées: date, heure, quelques chaînes de texte courtes et plusieurs entiers.

Actuellement, j'ai hérité d'une solution basée sur jffs2 et SQLite qui est loin d'être optimale car le fichier de base de données est parfois corrompu. Lorsque cela se produit, le fichier entier devient illisible et il est impossible de savoir s'il a été causé par un bogue dans jffs2, dans SQLite ou si le secteur flash était défectueux ou si le courant a été coupé au mauvais moment.

Existe-t-il une bibliothèque ou une combinaison système de fichiers / bibliothèque qui peut mieux m'aider à résoudre ce type de problème? Ou devrais-je simplement utiliser un fichier texte au format CSV?

Answer 1

Nous utilisons tout simplement syslogd sur une partition YAFFS2 sur une mémoire flash NAND, il semble bien fonctionner: lorsque les messages sont envoyés à l'enregistreur et que l'alimentation est coupée immédiatement après (< 100ms), le message est présent et la le journal ne semble jamais corrompu.

Ceci est basé sur l'observation plutôt que sur le fait que je sache explicitement que tout sera toujours cohérent de par sa conception, son esprit.

Answer 2

Je ne suis pas un expert des systèmes intégrés, mais je penserais qu'un CSV serait probablement le meilleur. En principe, elle ne peut pas être corrompue. Si c'est le cas, vous pouvez facilement voir l'erreur et la corriger manuellement (nouvelle ligne ou suppression d'une ligne). Je travaille sur la réception des données d'un système intégré dans lequel ils rencontrent de nombreux problèmes de corruption (partiellement sur le système et partiellement pendant le transfert de ligne téléphonique). Il serait très utile que ce soit dans un format de type CSV afin que nous puissions trouver les erreurs et les supprimer ou les corriger au lieu de corrompre l’ensemble des données.

Si vous n'avez pas besoin de chercher dans le système, un fichier CSV fonctionne parfaitement.

Answer 3

Un certain nombre de systèmes de fichiers intégrés (non compatibles avec la graisse) ont été conçus à cet effet. Je ne peux pas suggérer, car je n'en ai jamais utilisé, mais ici quelque chose de Google. Je suis sûr que vous pouvez creuser davantage, et j'espère que quelqu'un ici pourra vous donner plus d'informations, peut-être qu'il y a quelque chose de basé sur la GPL. La comparaison des différents systèmes de fichiers est ici

.

Answer 4

Deux fichiers csv / texte. Commencez une nouvelle paire à chaque redémarrage du système. Ecrivez chaque événement dans le premier fichier, rincez le fichier à stocker, écrivez l’enregistrement dans le second fichier, puis rincez à nouveau.

Ainsi, si vous rencontrez un problème lors de la première écriture, toutes les données de la deuxième copie (jusqu'à cette écriture) seront toujours là.

Assurez-vous que le vidage est un vidage complet du système de fichiers et pas seulement le vidage du tampon de clib.

Peut-être aussi placer les fichiers sur des systèmes de fichiers séparés. Réserver de la place avant vos besoins pourrait également contribuer à accélérer le processus.

Answer 5

Quelles installations sont à votre disposition? La meilleure option consiste souvent à se connecter à une ressource externe , par exemple, via syslog, SNMP, un socket brut ou un port série. Cela vous protège des journaux contre les désagréments sur le périphérique lui-même.

Si vous avez besoin de stocker les journaux en interne, j'ai trouvé que les fichiers en texte clair lisibles par un humain étaient la meilleure option pour les périphériques intégrés. Le & "Écrire / rincer &"; cycle est rapide, aucun outil n’est nécessaire pour les maintenir et vous pouvez les surveiller en temps réel. Si la taille du fichier pose problème, vous pouvez horodater avec un entier plutôt que du texte mis en forme, et vous pouvez utiliser un & "Identifiant d'événement & Numérique; pour abréger chaque journal (laissez uniquement les données spécifiques à l’instance sous forme de texte).