Se o meu programa detectar que uma perda de energia ocorrerá em alguns segundos, o que ela pode fazer para evitar corrupção de dados?

4

Um programa (que precisa ler e gravar de e para o sistema de arquivos) tem o recurso extra de poder se comunicar com um sensor externo. Por isso, tem a capacidade única de saber se uma perda de energia é iminente. O aviso que recebo é de apenas alguns (cerca de 3 a 5) segundos - não o suficiente para executar um desligamento completo. Alguns preciosos segundos podem ser adicionados, mas isso aumentaria os custos de hardware.

Como escrever em um arquivo não garante que o SO faça o trabalho agora , até fechar o arquivo pode, até onde eu sei, levar o SO a decidir que fará o fechamento mais tarde se ninguém mais tentar acessá-lo, como posso garantir que

  1. todas as gravações que eu faço agora serão salvas. (Após o aviso ser recebido, meu programa gravará alguns kilobytes em disco, mas pode ter havido grandes quantidades de dados gravados antes do recebimento do aviso, que pode ou não ainda ser finalizado pelo sistema operacional)
  2. Nenhum outro dano ocorre devido a um desligamento inadequado do sistema operacional.

Nota: por design, a perda de energia pode ser uma ocorrência regular. Também por design, nenhum outro "aplicativo de usuário" será executado no sistema (para que não tenhamos que nos preocupar, por exemplo, com um tocador de música, um ambiente de desenvolvimento, um editor de planilha e o Gimp executando e acessando o sistema de arquivos). / p>     

por vsz 23.09.2015 / 07:10

1 resposta

4

A principal coisa que você precisa fazer é emitir uma sync chamada do sistema. Há um utilitário sync que faz exatamente isso. Quando a chamada do sistema sync retornar, ela garante que qualquer operação de gravação do sistema de arquivos (em qualquer sistema de arquivos montado) que foi emitida antes da conclusão do sync .

Cabe ao design do aplicativo garantir que, se isso ocorrer no meio de uma sequência de operações de gravação, os dados sejam deixados em um estado utilizável. No entanto, se você tiver o luxo de um período de aviso garantido antes da perda de energia, poderá ter um design mais desleixado, desde que garanta uma resposta rápida ao aviso de perda de energia (que é difícil).

Com sistemas de arquivos de registro no diário, como ext4, se você sincronizar e depois desligar a energia, não obterá um fsck na reinicialização. No entanto, se algo causar uma gravação após a sincronização, acho que é possível, mas raro, que o fsck seja necessário. Se você quiser ter absoluta certeza, desmonte todos os sistemas de arquivos de leitura-gravação antes da perda de energia ou, pelo menos, remonte-os como somente leitura. Normalmente, você não pode fazer isso se houver arquivos abertos para gravação. Se o seu sistema executa o Linux, você pode usar seu recurso magic sysrq (você precisa ter certeza de que está ativado). Isso pode ser chamado programaticamente gravando um caractere em /proc/sysrq-trigger : echo u >/proc/sysrq-trigger force-remonta todos os sistemas de arquivos como somente leitura (isso inclui o efeito de sincronização). Você também pode usar essa interface para reinicializar ( b ) ou desligar ( o ), se isso for útil em sua configuração.

Se o aviso de perda de energia pode ser cancelado, você pode ligar para sync : isso não tem efeito negativo em nada além de desempenho. Um force-mount-read-only, por outro lado, não é recuperável em geral, então faça isso somente quando você tiver se comprometido a reinicializar.

Para a maioria das configurações que correspondem à sua descrição, essa é uma reação razoável a um aviso de perda de energia:

  1. Envie um sinal personalizado (por exemplo, SIGUSR1 ou SIGPWR) para o processo afetado, instruindo-o a confirmar ou abortar rapidamente qualquer transação em andamento, se isso puder ajudar a tornar a recuperação na próxima inicialização mais fácil.
  2. Aguarde por parte do atraso antes da perda de energia esperada. Calibre isso para ter o suficiente para as operações restantes.
  3. Escreva uma mensagem de log.
  4. echo u >/proc/sysrq-trigger
por 24.09.2015 / 02:11