Registro de datos de tipo Blackbox

Question

En una aplicación embebida de Linux que estoy desarrollando, existe la necesidad de registrar algunos eventos que ocurren de vez en cuando. Estos registros se guardan en un dispositivo flash MTD y una vez escritos no hay necesidad de cambiarlos o realizar búsquedas eficientes, pero se requiere acceso de lectura para mostrar los datos al usuario. Un gran problema es que la energía puede desaparecer en cualquier momento, sin una secuencia de apagado adecuada. La frecuencia con la que ocurren estos eventos puede ser muy lenta (días / semanas), pero varios de ellos ocurrirán a la vez. Los datos que se guardarán para cada evento están fuertemente tipados: fecha, hora, un par de cadenas de texto cortas y varios enteros.

Actualmente heredé una solución basada en jffs2 y SQLite que está lejos de ser óptima porque el archivo DB a veces se corrompe. Cuando esto sucede, todo el archivo se vuelve ilegible y no hay forma de entender si fue causado por un error en jffs2, o en SQLite o si el sector de flash era malo, o si la energía se cortó en el momento incorrecto.

¿Existe una biblioteca o una combinación de sistema de archivos / biblioteca que pueda ayudarme mejor a resolver este tipo de problema? ¿O debería usar un archivo de texto con un formato similar a CSV?

Answer 1

Estamos usando syslogd viejo y simple en una partición YAFFS2 en flash NAND, parece funcionar bien: cuando se envían mensajes al registrador y se corta la energía inmediatamente después (< 100ms) el mensaje está ahí y el el registro nunca parece corromperse.

Esto se basa en la observación más que en mi conocimiento explícito de que todo siempre será coherente por diseño, mente.

Answer 2

No soy experto en sistemas embebidos, pero creo que un CSV probablemente sería lo mejor. Básicamente no se puede dañar, o si lo hace, entonces puede ver fácilmente el error y corregirlo manualmente (nueva línea o simplemente eliminar una línea). He estado trabajando para recibir los datos de un sistema incorporado donde tienen muchos problemas de corrupción (parcialmente en el sistema y parcialmente durante la transferencia de la línea telefónica). Sería muy útil si estuviera en un formato de tipo CSV para poder encontrar los errores y eliminarlos o corregirlos en lugar de dañar todo el conjunto de datos.

Si no necesita buscar dentro del sistema, un CSV funciona perfectamente.

Answer 3

Hay varios sistemas de archivos incrustados (no compatibles con grasa) que se diseñaron exactamente para este propósito. No puedo sugerir ya que nunca usé uno, pero aquí algo de google. Estoy seguro de que puede cavar más, y espero que alguien aquí pueda proporcionar más información, puede haber algo basado en GPL. La comparación de diferentes sistemas de archivos está aquí

Answer 4

Dos archivos csv / text. Inicie un nuevo par cada vez que se reinicie el sistema. Escriba cada evento en el primer archivo, vacíe el archivo a almacenar, escriba el registro en el segundo archivo y luego vuelva a enjuagarlo.

De esta manera, si se bloquea durante la primera escritura, todos los datos en la segunda copia (hasta esa escritura) seguirán allí.

Asegúrese de que la descarga sea una descarga completa del sistema de archivos y no solo la descarga del búfer clib.

Quizás también coloque los archivos en sistemas de archivos separados. Reservar espacio antes de lo que necesita también podría ayudar a acelerar el proceso.

Answer 5

¿Qué instalaciones están disponibles para usted? La mejor opción es a menudo iniciar sesión en un recurso externo, por ejemplo a través de syslog, SNMP, socket sin procesar o puerto serie. Esto protege sus registros de incómodos en el propio dispositivo.

Si necesita almacenar registros internamente, he encontrado que los archivos de texto sin formato legibles por humanos son la mejor opción en los dispositivos integrados. & Quot; escribir / vaciar & Quot; El ciclo es rápido, no se necesitan herramientas para mantenerlos y puede monitorearlos en tiempo real. Si el tamaño del archivo es un problema, puede marcar la hora con un número entero en lugar de texto formateado, y puede usar un & Quot; ID de evento & Quot; para abreviar cada registro (deje solo los datos específicos de la instancia como texto).