log tipo de dados Blackbox

Question

Em um aplicativo de Linux embarcado que estou desenvolvendo, há a necessidade de registrar alguns eventos que acontecem ao longo do tempo. Esses registros são salvos em um dispositivo flash MTD e uma vez escrito, não há necessidade de mudá-los ou fazer pesquisas eficientes, mas o acesso de leitura é necessária para mostrar a parte de trás de dados para o usuário. Um grande problema é que o poder pode ir embora a qualquer momento, sem uma sequência de encerramento adequado. A frequência destes eventos ocorrem pode ser muito lenta (dias / semanas), mas vários deles irá ocorrer ao mesmo tempo. Os dados a serem salvos para cada evento é fortemente tipado:. Data, hora, um par de cadeias de texto curtas e vários inteiros

Atualmente eu herdei uma solução baseada em jffs2 e SQLite que está longe de ser ideal porque o arquivo DB, por vezes, ser corrompidos. Quando isso acontece, todo o arquivo fica ilegível e não há maneira de entender se ele foi causado por um erro no jffs2, ou em SQLite ou se o setor de flash era ruim, ou se a alimentação foi cortada na hora errada.

Existe uma biblioteca ou uma combinação de sistema de arquivos / biblioteca que pode melhor me ajudar a resolver este tipo de problema? Ou devo apenas usar um arquivo de texto com um CSV-como formato?

Answer 1

Estamos usando plain syslogd velho para uma partição YAFFS2 em flash NAND, parece funcionar bem: quando as mensagens são enviadas para o logger e poder é removido imediatamente após (<100 ms), a mensagem está lá eo log nunca aparece para corrupto.

Esta é baseada na observação ao invés de eu saber explicitamente que tudo será sempre consistente, design, mente.

Answer 2

Eu não sou especialista em sistemas embeded, mas eu acho que um CSV provavelmente seria melhor. Ele basicamente não pode ser corrompido, ou se isso acontecer, então você pode facilmente ver o erro e corrigi-lo manualmente (nova linha ou apenas a remoção de uma linha). Tenho vindo a trabalhar ao receber os dados de um sistema embarcado, onde eles têm um monte de problemas de corrupção (parcialmente no sistema e parcialmente durante a transferência de linha telefônica). Seria muito útil se fosse em um formato do tipo CSV para que pudéssemos encontrar os erros e remover ou corrigi-los, em vez de corromper todo o conjunto de dados.

Se você não está precisando de pesquisa dentro do sistema, em seguida, um CSV funciona perfeitamente.

Answer 3

Há um número de sistemas de arquivos incorporados (não de gordura compatível) que concebido exatamente para esta finalidade. Eu não posso sugerir uma vez nunca usou um, mas aqui algo do Google. Tenho certeza que você pode cavar mais, e espero que alguém aqui pode fornecer mais informações, pode ser há algo GPL base. Comparação de diferentes sistemas de arquivos são aqui

Answer 4

arquivos

Dois CSV / texto. Iniciar um novo par cada vez que o sistema for reiniciado. Escreva cada evento para o primeiro arquivo, lave o arquivo para armazenar, gravar o registro para o segundo arquivo, em seguida, lave novamente.

Desta forma, se você falhar durante a primeira gravação de todos os dados na segunda cópia (até que escrever) ainda estará lá.

Certifique-se o rubor é um flush sistema de arquivo completo e não apenas o rubor tampão clib.

Talvez, também, colocar os arquivos em sistemas de arquivos separados. Reservando à frente espaço do que você precisa também poderia ajudar a acelerar o processo.

Answer 5

Quais as facilidades estão disponíveis para você? A melhor opção é muitas vezes a log para um recurso externo, , por exemplo, via syslog, SNMP, socket raw, ou porta serial. Isso protege você registra a partir unpleasantries no próprio dispositivo.

texto simples Se você precisa para armazenar os logs internamente, eu encontrei, arquivos legíveis para ser a melhor opção em dispositivos embarcados. O ciclo "write / nivelado" é rápido, há ferramentas são necessárias para mantê-las, e você pode monitorá-los em tempo real. Se o tamanho do arquivo é um problema, você pode timestamp com um inteiro, em vez de texto formatado, e você pode usar um formato numérico "ID do evento" para abreviar cada log (deixar apenas os dados específicos da instância como texto).