Qual sistema de arquivos oferece a melhor proteção para proteger dados contra corrupção devido à perda de energia?

Estou executando um sistema incorporado pequeno uClibce busyboxbaseado em um dispositivo x86. Estou usando um initramfs, mas também montando um ext3diretório personalizado em um dispositivo flash compacto no modo IDE que estou usando para armazenar dados de log de medição persistentes criados por um aplicativo c ++ gravado personalizado. Eu escolhi o ext3sistema de arquivos, pois é recomendado para segurança contra perda de energia ao usar unidades CF no modo IDE em alguns livros que li ( Construindo sistemas Linux embarcados por Karim Yaghmour e Embedded Linux Primer por Christopher Hallinan). Isso é particularmente importante e os dados são críticos.

No entanto, devido a alguns dos comentários da minha pergunta anterior Confusão sobre como restaurar arquivos ext3 corrompidos se ocorrer falta de energia durante a gravação de um arquivo , parece que, de fato, este sistema de arquivos não oferece garantia de segurança contra corrupção de dados devido à energia perda. Então eu gostaria de saber se

1. É ext3realmente a melhor escolha para esta configuração?
2. A perda de energia durante uma operação de gravação de disco apenas corrompe a parte dos dados que estou anexando ao arquivo periodicamente ou pode corromper o arquivo inteiro ?
3. Os dados que não estão sendo gravados no ponto de perda de energia são completamente seguros? Em particular, existe algum risco de que meu initramfs.cpioarquivo também fique corrompido?
4. Existe algum método que eu possa usar no código do meu aplicativo para proteger os dados (por exemplo, criar uma partição extra e gravar meus dados em imagens espelhadas para que haja sempre duas cópias) - a velocidade não é um problema real para as operações de cópia tão caras do meu aplicativo são aceitáveis.

Vi e li as respostas para esta pergunta relacionada: Os sistemas de arquivos com registro em diário garantem contra a corrupção após uma falha de energia? , mas não cobre completamente algumas das coisas que estão me confundindo.

Percebo que estou fazendo muitas perguntas, mas parece que, apesar de ler muito material, tive uma falha fundamental em entender os riscos para meus dados em caso de perda de energia.

Como em todas as questões relacionadas à segurança, não há garantias, mas você também precisa equilibrar risco (e custo) e probabilidade. Por experiência (e venho executando dezenas de * nix boxen desde a idade das trevas), nunca tive uma corrupção significativa no sistema de arquivos causada por energia.

Algumas dessas máquinas estavam rodando em sistemas de arquivos não-diários (ufs e ext2 geralmente). Alguns deles foram incorporados e alguns eram celulares como o Nokia N900 - portanto, uma boa fonte de alimentação não era garantida.

Não é que a corrupção do sistema de arquivos não possa acontecer, é apenas que a probabilidade de isso acontecer é baixa o suficiente para que não o preocupe. Ainda assim, não há razão para não proteger suas apostas.

Em resposta às suas perguntas literais:

1. Pelo menos o primeiro livro que você referenciou foi escrito antes ext4- quando o autor sugere o uso ext3, eles estão realmente dizendo 'não use sistemas de arquivos instáveis ​​ou não-diários como ext2'). Tente ext4, é bastante maduro e possui algumas opções decentes para discos não giratórios, o que pode prolongar a expectativa de vida do seu dispositivo flash.
2. As chances são de que você perderia o último bloco ou dois, não o arquivo inteiro. Com um sistema de arquivos em diário, essa será a única perda. Existem cenários de falha em que eu pude ver dados aleatórios pulverizados no arquivo, mas eles parecem quase tão prováveis ​​quanto um micrometeorito sendo esmagado diretamente no seu dispositivo incorporado.
3. Veja 2. Nada é 100,00% seguro.

4. Se você tiver um segundo canal IDE, cole um segundo cartão CF e faça um backup do sistema de arquivos periodicamente. Existem algumas maneiras de fazer isso: rsync, cp dump, dd, mesmo usando o md(4)(software RAID) dispositivo (você adicionar a segunda unidade, ocasionalmente, deixe-o sincronizar e depois removê-lo - se ambos os dispositivos são ao vivo o tempo todo, eles correm o mesmo risco corrupção do sistema de arquivos). Se você usa o LVM, pode até capturar instantâneos. Para um dispositivo incorporado de coleta de dados, eu usaria apenas uma solução ad hoc que monta o segundo sistema de arquivos, copia sobre o log de dados e desmonta-o imediatamente. Se você estiver preocupado com a boa imagem do dispositivo, cole uma segunda cópia do gerenciador de inicialização e todas as imagens de inicialização necessárias no segundo dispositivo e configure o computador para inicializar a partir de um cartão CF.

   Eu não confiaria em uma segunda cópia no mesmo dispositivo, porque os dispositivos de armazenamento falham com mais frequência do que os sistemas de arquivos estáveis. Com muito mais frequência, na minha experiência até agora (no trabalho, houve uma meia piada amarga sobre as extraordinariamente altas chances de falhas de disco na sexta-feira à tarde. Foi um evento quase semanal por um tempo). Se o disco está girando ou não, pode falhar. Portanto, mantenha seus ovos em duas cestas, se puder, e você protegerá seus dados melhor.

   Se os dados forem particularmente sensíveis, eu faria visitas regulares ao dispositivo, trocaria o CF de backup por um novo e reinicializaria, deixando fscktodos os seus sistemas de arquivos em boa medida.

Parece-me que o que uma implementação de sistema de arquivos pode alcançar em caso de perda repentina de energia é limitada - afinal, ela está realmente interagindo com o hardware, então o que acontece entre o momento em que envia dados / instruções ao hardware e quando obtém uma resposta está fora de controle. Se houvesse um sistema de arquivos que pudesse contornar esse problema, você já o teria ouvido.

Por isso, uma estratégia para proteger dados críticos se beneficiará mais das decisões tomadas no nível do hardware , por exemplo, usando uma fonte de alimentação ininterrupta. Provavelmente isso não é tão viável na sua situação.

Você disse que o desempenho não é realmente um grande problema, portanto, faça um uso criterioso fsync().

A perda de energia durante uma operação de gravação de disco apenas corrompe a parte dos dados que estou anexando ao arquivo periodicamente ou pode corromper o arquivo inteiro?

Eu tenho usado sistemas de arquivos extN pessoalmente e em servidores da Internet de baixo e médio tráfego há anos e, como Alexios, não vi muita corrupção devido a falta de energia (apesar de ser justo, os servidores têm UPS e não me lembro um deles realmente indo por esse caminho). Uma questão muito mais séria é a corrupção causada por falha de hardware, que diferentes sistemas de arquivos podem (novamente) ser cada vez menos capazes de lidar com o problema, mas (novamente) isso está fundamentalmente além do controle deles e eles não podem impedi-lo.

Ocasionalmente, vi arquivos perdidos ou truncados para o tamanho zero. Presumo que há uma boa chance de que eles possam ser recuperados de alguma forma; isso não foi necessário para mim, pois eles foram salvos em backup. Na maioria das vezes, se há algo errado, fsckparece lidar com isso.

Os dados que não estão sendo gravados no ponto de perda de energia são completamente seguros? Em particular, existe algum risco de que meu arquivo initramfs.cpio também possa ficar corrompido?

Eu acho que o risco é realmente muito baixo devido apenas a uma falha de energia, exceto pelo tipo de corrupção que o armazenamento flash pode estar sujeito devido ao aumento de energia que pode acompanhar as falhas de energia - com as quais não tenho experiência, mas espero que você tenha pensado sobre e pesquisou isso.

Existe algum método que eu possa usar no código do meu aplicativo para proteger os dados?

Vale repetir o argumento sobre fsync () . Objetos C ++ / iostream não possuem um método para isso (:: flush e :: sync não são fsync), mas tudo que você precisa é de um descritor de arquivo.

O ZFS é definitivamente um sistema de arquivos protegido contra corrupção por design e possivelmente o único. No entanto, não tenho certeza sobre a disponibilidade de implementações do ZFS (baseadas em fusíveis ou nativas) para plataformas baseadas no uClinux.

Há pelo menos um sistema de arquivos comercial que faz um trabalho tremendo, certificando-se de que o sistema de arquivos quase não possa ser corrompido devido a falhas de energia e que os únicos dados que você corre o risco de perder são os dados que foram adicionados quando a energia acabou.

O lado negativo é que é muito caro; no lado superior, eles oferecem grande suporte. Devido às despesas, é realmente apenas uma opção para produtos de alto risco e / ou alto volume. Como equipamentos embarcados críticos, por exemplo, na produção de petróleo e gás, que precisam garantir a integridade do sistema em condições de operação "incertas" (por exemplo, falta de energia frequente etc.).

Confira DataLight (empresa) e / ou produto " Reliance NITRO ". (A confiança é o seu legado e a solução segura, mas não muito eficaz, substituída pela Reliance NITRO ). Mesmo que você não tenha dinheiro para usar esse sistema, eles têm alguns artigos muito bons discutindo como o sistema funciona, por que é mais confiável do que, por exemplo, ext3 e ext4.

Minhas desculpas se isso for lido como um anúncio, só quero apontar opções.