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

Question

Estou executando um pequeno sistema integrado baseado em uClibc e busybox em um dispositivo x86. Estou usando um initramfs, mas também estou montando um diretório ext3 personalizado em um dispositivo flash compacto no modo IDE que estou usando para armazenar dados de registro de medição persistentes criados por um aplicativo c ++ escrito personalizado. Eu escolhi o sistema de arquivos ext3 como é recomendado para segurança contra perda de energia ao usar drives CF no modo IDE em alguns livros que eu li ( Building Embedded Linux Systems 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 com a forma de restaurar arquivos ext3 corrompidos se ocorrer queda de energia durante a gravação de um arquivo , parece que na verdade este sistema de arquivos não oferece a garantia de segurança contra corrupção de dados devido à perda de energia. Então eu gostaria de saber se

1. A ext3 é realmente a melhor escolha para essa configuração?
2. A perda de energia durante uma operação de gravação de disco só corrompe a parte dos dados que estou anexando ao arquivo periodicamente ou pode corromper o arquivo inteiro ?
3. Os dados que estão não sendo gravados no ponto de perda de energia são completamente seguros? Em particular, existe algum risco de que meu arquivo initramfs.cpio possa se corromper também?
4. Existe algum método que eu possa usar no código do meu aplicativo para proteger os dados (ou seja, 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 meu aplicativo operações de cópia caras são aceitáveis.

Eu vi e li as respostas para esta pergunta relacionada: O journaling filesystem garante contra a corrupção após uma falha de energia? , mas não cobre algumas das coisas que estão me confundindo.

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

    

Answer 1

Assim como todas as coisas relacionadas à segurança, não há garantias, mas você também precisa equilibrar o risco (e o custo) com a probabilidade. Pela experiência (e eu venho executando dúzias de * nix boxen desde a idade das trevas), eu nunca tive uma corrupção significativa do sistema de arquivos causada pela energia.

Algumas dessas máquinas estavam sendo executadas em sistemas de arquivos não dedicados (geralmente, ufs e ext2). Alguns deles foram incorporados, e alguns eram telefones celulares como o Nokia N900 - então, uma boa fonte de alimentação não era garantida de todo.

Não é que a corrupção do sistema de arquivos não pode acontecer, é apenas que a probabilidade de isso acontecer é baixa o suficiente para que você não se 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ê mencionou foi escrito antes de ext4 - quando o autor sugere o uso de ext3 , ele está realmente dizendo "não use sistemas de arquivos instáveis ou não baseados em dia, como ext2 "). Experimente ext4 , é bastante maduro e tem algumas opções decentes para discos não giratórios que podem estender a expectativa de vida do seu dispositivo flash.
2. Provavelmente, você perderia o último bloco ou dois, não o arquivo inteiro. Com um sistema de arquivos journalled, esta será a única perda. Existem cenários de falha em que eu pude ver dados aleatórios espalhados pelo arquivo, mas eles parecem tão parecidos quanto um micrometeorito esmagando o dispositivo incorporado.
3. Ver 2. Nada é 100,00% seguro.

4. Se você tiver um segundo canal IDE, coloque 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 dispositivo md(4) (software RAID) (você adiciona a segunda unidade ocasionalmente, deixa sincronizar e, em seguida, a remove - se ambos os dispositivos estiverem ativos o tempo todo, eles correm o mesmo risco de corrupção do sistema de arquivos). Se você usa o LVM, pode até capturar instantâneos. Para um dispositivo integrado de coleta de dados, eu usaria apenas uma solução ad hoc que monta o segundo sistema de arquivos, copia o log de dados, o desmonta imediatamente. Se você estiver preocupado com o dispositivo ter uma boa imagem de inicialização, coloque 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 do 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. Muito mais vezes, na minha experiência até agora (no trabalho, havia uma meia piada amarga sobre as chances extraordinariamente altas de falhas de disco na tarde de sexta-feira. Era quase um evento 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á melhor seus dados.

   Se os dados forem particularmente confidenciais, eu pagaria visitas regulares ao dispositivo, trocaria o CF de backup por um novo e reinicializaria, permitindo que ele fsck de todos os seus sistemas de arquivos seja uma boa medida.

Answer 2

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

Por causa disso, uma estratégia para proteger dados críticos se beneficiará mais das decisões tomadas em um nível 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 é um grande problema, por isso, faça um uso criterioso de fsync() .

Does power loss during a disc write operation only corrupt the portion of data I am appending to the file periodically or can it corrupt the entire file?

Eu venho usando sistemas de arquivos extN pessoalmente e em servidores de internet de tráfego baixo e médio há anos, e como Alexios eu não vi muita corrupção devido a falta de energia (embora, para ser justo, os servidores têm UPS e eu posso 'Não me lembro de um deles realmente indo por esse caminho). Um problema muito mais sério é a corrupção de falhas de hardware, que sistemas de arquivos diferentes podem (mais uma vez) ser mais e menos capazes de lidar com o problema, mas (novamente) isso está fundamentalmente fora de seu controle e eles não podem evitá-lo. >

Ocasionalmente, vi arquivos perdidos ou truncados para tamanho zero. Eu presumo que há uma boa chance de que estes sejam recuperáveis de alguma forma; isso não era necessário para mim, como eles foram copiados. Na maioria das vezes, se houver algo errado, fsck parece lidar com isso.

Is data that is not being written at the point of power loss completely safe? In particular, is there any risk that my initramfs.cpio file can become corrupt also?

Acho que o risco é realmente muito baixo devido a uma falha de energia, exceto pelo tipo de corrupção que o armazenamento flash pode estar sujeito devido à oscilação de energia que pode acompanhar falhas de energia - com as quais não tenho experiência, mas espero que você ter pensado e pesquisado isso.

Is there any method I can use in my application code to protect the data?

Vale a pena repetir o ponto 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 é um descritor de arquivo.

    

Answer 3

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.

    

Answer 4

Há pelo menos um sistema de arquivos comercial que faz um tremendo trabalho certificando-se de que o sistema de arquivos quase não pode ser corrompido devido a falhas de energia e que os únicos dados que você arrisca perder são dados que foram sendo adicionados à medida que a energia foi sendo fora.

O lado negativo é que é muito caro, no lado de cima eles oferecem um ótimo suporte. Devido à despesa, é realmente apenas uma opção para produtos high stakes e / ou de alto volume. Como o equipamento incorporado crítico em, e. produção de petróleo e gás que precisam garantir a integridade do sistema dentro de condições de operação "incertas" (por exemplo, frequentes quedas de energia, etc.).

Confira DataLight (empresa) e / ou produto " Reliance NITRO ". (Reliance é sua solução legada e segura, mas não muito eficaz, substituída por 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 destacar as opções.