Use com segurança cartões SD quando a energia puder sair a qualquer momento

Question

Estamos trabalhando em um pequeno sistema Linux embarcado (2.6.35-ish) com um pequeno dispositivo NAND interno para o sistema operacional e aplicativos (250-500Meg) e um cartão SD com cartões SD de SD de 8Gb para dados.

A energia da unidade pode ser cortada a qualquer momento.

O sistema deve armazenar dados em cartões SD. Esses dados são muito importantes ... é todo o propósito do sistema. Os sistemas são geralmente totalmente desconectados de qualquer rede em locais remotos e os dados são recuperados via sneakernet a cada 4-8 semanas.

Atualmente, temos simplesmente o VFAT nos cartões SD. Isso foi principalmente para que os primeiros clientes pudessem copiar os dados manualmente para seus laptops Win7.

No entanto, agora estou preocupado que seja apenas uma questão de tempo até que uma queda de energia na hora errada cause perda de dados.

Qual é a melhor maneira de configurar um sistema desse tipo para evitar a perda de dados? O JFFS2 soa como o que eu gostaria em termos de como ele grava dados (e as necessidades de desempenho não são altas), mas soa um pouco desajeitado usar o block2mtd, etc. Eu também não tenho certeza de como o nivelamento do cartão irá interagir com isso.

Qual é a melhor maneira de fazer isso?

EDITAR

Agora estou pensando em deixar o sistema de arquivos VFAT e alocar arquivos de tamanho diário de cada vez, preenchidos com 0xFF, que devem limitar muito a exposição a falhas no ciclo de energia. Eu poderia, então, apenas anexar registros dentro desses blocos pré-criados, e esperançosamente os cartões SD não são tão estúpidos que eles apagam / usam gravações de nível para regiões 0xFF.

Eu posso usar o noatime, mas existe um equivalente no tempo de VFAT para impedir gravações no campo de tempo modificado? Eu precisaria de alguma maneira para impedir qualquer atualização de metadados até que um arquivo de um novo dia seja criado.

EDIT 2

Alguém na troca de pilha eletrônica me lembrou que também há dados ECC na NAND, então não há como evitar a necessidade de apagar.

Então, o JFFS2 via block2mtd seria apropriado nesta situação?

EDIT 3

É pior do que eu pensava. Os cartões SD que eu tenho irão apagar os blocos de dados, mesmo se você escrever exatamente o mesmo conteúdo para o disco. Os eraseblocks são 64KB, e isso é muito grande para atrasar completamente as gravações. Eu vou armazenar até 128KB de dados em flash NAND (que eu posso controlar o comportamento de gravação de), em um tipo de diário e, em seguida, escrever 128KB blocos para um arquivo de 128KB em uma partição VFAT no cartão SD (em caso outros cartões SD tenham 128 KB de apagamentos).

    

Answer 1

Bem, a maneira que você pode consertar isso é consertar o problema "poder ser cortado a qualquer momento". É impossível adicionar um minuto de energia da bateria?

Alternativamente, talvez você possa usar dois cartões SD. Escreva os dados para um cartão, sincronize, escreva para o outro. Cada bloco de dados precisaria de um checksum e um número de bloco, mas mesmo com algumas falhas de energia bem ruins, uma das placas deveria estar certa.

Seu problema básico será o nivelamento de desgaste nos cartões SD, que depende do fornecedor do cartão (e talvez até mesmo do lote, eles podem ser alterados sempre que possível). Provavelmente não manipula a falta de energia corretamente. E dependendo do que isso faz, isso pode não apenas significar corromper o bloco no qual você está escrevendo.

1. Suponha um cartão trivialmente pequeno - 3 blocos (flash). O bloco 1 recebeu mais gravações do que 2 ou 3. Vou chamar os blocos físicos pelo número e os blocos lógicos A, B, C por letra. Agora, A = 1, B = 2, C = 3.
2. Você emite uma gravação no bloco A. Cartão SD é como aha! precisamos usar nivelamento aqui, senão o bloco 1 vai se desgastar antes de 2 e 3. Ele decide trocar os blocos 1 e 2.
3. Ele lê o bloco 1 na posição RAM i (no cartão SD, não na RAM do sistema). Atualiza a parte que você queria mudar.
4. Ele lê o bloco 2 na posição da RAM ii
5. Apaga o bloco 1
6. Grava a posição II da RAM no bloco 1.
7. Atualiza a tabela de mapeamento para dizer B = 1
8. Apaga o bloco 2.
9. Grava a posição RAM i no bloco 2.
10. Atualiza a tabela de mapeamento para dizer A = 2

Naturalmente, "atualiza a tabela de mapeamento" nem sempre é trivial. E a ordem de 5 a 10 poderia ser diferente (se todas elas forem completas, não importa, bem, os apagamentos devem vir antes das gravações, é claro). Mas uma falha de energia acontece, você pode acabar com não apenas A corrompido (como você espera), mas B também. Ou, se ocorrer falha de energia durante uma atualização de mapeamento, quem sabe que tipo de corrupção causará.

    

Answer 2

Algo semelhante foi discutido em electronics.stackexchange.com: Como protejo o cartão SD contra falhas de energia inesperadas?

Uma resposta lateral que funciona em tandem com soluções de software é olhar para o hardware (havia uma pergunta no ESE sobre isso também, mas não consigo encontrá-lo agora; não foi estritamente sobre cartões SD, apenas sobre dispositivos perdendo energia e como detectar isso e agir sobre isso).

O conto é: você pode não ter bateria, mas sua fonte de alimentação tem alguns capacitores bastante grandes para suavizar o fornecimento. Basicamente, o poder não desaparece. A tensão diminui. Provavelmente, há um circuito / circuito de proteção contra proteção contra energia que ativa o sinal RESET no sistema embarcado quando a tensão cai abaixo de um determinado ponto. Placas-mãe de PC também têm essas e elas respondem ao sinal "POWEROK" da PSU. O que isto significa é que, quando a energia é desligada, o computador será interrompido à força por alguns milissegundos antes que a tensão caia abaixo dos níveis seguros. Durante esse período, periféricos como cartões SD ainda estão ligados, mas não há mais transações provenientes do computador.

É muito provável que um cartão SD tenha tempo suficiente para concluir todas as transações pendentes, incluindo o uso do nivelamento de desgaste, antes da falta de energia. Melhorar sua fonte de alimentação com um capacitor grande o suficiente ou usar um próximo ao cartão SD pode ajudar a garantir isso, mas você sempre pode experimentar sua plataforma como ela é. É bem provável que retenha energia por tempo suficiente.

Se o aspecto de hardware do problema não for um problema, você poderá solucionar apenas os problemas de software. O ides do derobert de usar dois cartões para redundância não é ruim, e usar um sistema de arquivos padrão como o VFAT roda menos de risco de confundir os algoritmos de nivelamento de desgaste do cartão.

De qualquer forma, pode ser que você não tenha muito problema. Supondo que um bloco no seu cartão possa sobreviver a 100 gravações (conservador - mas tente obter cartões de boa qualidade!), E usando cartões de 8GB, você terá escrito 800 GB no momento em que o primeiro bloco morrer (estatisticamente falando, é claro).

    

Answer 3

Para segurança de dados em um ambiente com a possibilidade de cortes de energia e segurança geral dos dados, você deve considerar ainda mais pontos.

NÃO UTILIZE Células MLC para armazenamento, apenas o SLC tem um tempo de retenção de dados que é suficiente. Então, esses cartões SLC podem ter firmware inteligente, alguns não podem sob qualquer estado ser corrompido por perda de energia. Eles reconhecem o corte de energia medindo e assegurando que o último bloco seja escrito por completo.

Esses cartões são mais caros e um pouco mais lentos que as células MLC. Veja fornecedores como swissbit para cartões.

    

Answer 4

Tivemos um problema com o nosso SD, sistema de arquivos raiz ext2 sendo corrompido em falhas de energia inesperadas. Primeiro de tudo, fazemos o sistema rodar com uma montagem de raiz somente leitura. Como precisávamos de algum armazenamento gravável (mas não éramos registros de dados), configuramos uma segunda partição como gravável. Para minimizar o dano de FS em caso de falha de energia inesperada, transformamos isso em uma partição ext3, mesmo que isso cause pelo menos o dobro de gravações físicas na placa. Esta combinação (mas eu admito que nossas gravações segundo partições são pouco frequentes em comparação com um registrador de dados) parece correr sem problema. Tão longe. (Sistemas instalados por cerca de 30 meses em instalações profissionais)