corrupção do sistema de arquivos Linux devido a desligamento incorreto (fs ext4)?

Question

Eu tenho gerenciado muitos servidores Linux, é muito fácil de jogar com servidores Linux do que qualquer outro sistema operacional. Mas às vezes me deparo com um problema com o sistema operacional Linux é que, a corrupção do sistema de arquivos. Esse problema não ocorre no servidor Windows.

Eu procurei uma solução na Internet em detalhes, principalmente estas são sugestões dadas por todos.

1. Mantenha um backup & restaurar

Meus comentários == > Concordou em 100%, mas eu estou procurando uma solução, onde eu não preciso lutar para restaurar um sistema operacional com falha.

2. Executar fsck

Meus comentários == > Na minha experiência, em algum momento introduz problemas adicionais.

3. Fazer um desligamento / reinicialização adequado.

Meus comentários == > Todo mundo quer desligar / reiniciar corretamente. Estou falando de um cenário raro, em que o servidor não está respondendo ou não consigo desligar ou reinicializar corretamente

4. Btrfs == >

Meus comentários == > não estável o suficiente para produção

5. Atualizar para o Ext4

Meus comentários == > já usando ext4

6. Atualize seu disco rígido Meus comentários == > Nós encontramos o problema não devido à falha do disco, é principalmente devido ao desligamento inadequado.

Meu problema com o fsck:

1. fsck corrompe o sistema de arquivos em algum momento quando executamos com a opção -y

2. O fsck leva cerca de 1 ou 2 dias para consertar o sistema, o que não é bom para mim em um ambiente de produção

A minha pergunta é, até que o btrfs se torne estável. Existe algum trabalho para resolver este problema?

Como, "sincronizar" o sistema de arquivos uma vez em alguns minutos. ou Escrevendo algum script para sincronizar todas as alterações do sistema de arquivos antes de reinicializar

Estou procurando uma solução para esse problema em vez de sugestões.

    

Answer 1

ext4 deve ser resistente contra a extração do plugue. No entanto, para ser assim, requer que o subsistema de armazenamento não perca escritas comprometidas.

Primeiro, confirme que você não está montando com barrier=0 / nobarrier . Isso geralmente melhora o desempenho, ao custo de corrupção, se um desligamento adequado não for executado. Além disso, verifique seus logs de kernel para ter certeza de que as barreiras não estão sendo desativadas pelo ext4 porque algo na pilha não as suporta.

A próxima coisa a tentar, pelo menos em discos magnéticos (não-SSD) é desativar o cache de gravação de disco. Às vezes, os discos mentem sobre quando eles realmente gravaram dados para os discos - isso pode melhorar o desempenho (contanto que a energia não se apague). Geralmente você pode fazer isso com hdparm -W0 (para IDE / SATA) ou sdparm --clear=WCE (para SCSI / SAS). Estes podem precisar ser adicionados aos seus scripts de inicialização, como especialmente com SATA, ele pode ser redefinido para o padrão pelo ciclo de energia.

Existe um script (bastante antigo) para confirmar que o cache de gravação não está perdendo dados; veja post do blog diskchecker.pl de Brad Fitzpatrick para o script e como usá-lo.

Se você está em SSDs e está vendo o problema, infelizmente só precisa encontrar discos diferentes.