ext4 filesystems freqüentemente corrompendo

Question

Temos interrupções ocasionais de energia em nosso ambiente, o que parece causar corrupção de dados em nossas máquinas Ubuntu com sistemas de arquivos ext4.

A meu entender, o padrão do ext4 é usar data=ordered

O que é descrito como "Todos os dados são forçados diretamente para o sistema de arquivos principal antes de seus metadados serem confirmados no diário".

Isso significa que, se houver uma queda de energia e a operação para gravar no disco for interrompida, pode haver corrupção do sistema de arquivos?

Se eu quiser eliminar completamente a corrupção do sistema de arquivos devido a quedas de energia, eu acho que usaria data=journaled . Há algum impacto negativo nisso que não seja um impacto no desempenho?

Bônus: Como eu mudo o tipo de registro no meu sistema de arquivos de data=ordered para outro. Eu estou supondo que eu preciso fazer modificações no diário, mas não tenho certeza de como ou em que ordem executar essas operações.

Está ficando muito chato que o Ubuntu (initramfs) não tenha nenhum utilitário de recuperação de sistema de arquivos, então, qualquer maneira que possamos evitar que tenhamos que inserir um live cd é ótima.

Meu / etc / fstab

# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
#                
proc            /proc           proc    defaults        0       0
# / was on /dev/sda1 during installation
UUID=9cd71f51-53bb-44c7-affa-14293e59d596 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=5568cee1-a50b-4409-ad67-cdc5bfb592a3 none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0

Versão do SO

-bash-4.0# uname -a
Linux LG-F3-19 2.6.31-14-server #48-Ubuntu SMP Fri Oct 16 15:07:34 UTC 2009 x86_64 GNU/Linux
-bash-4.0# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 9.10
Release:        9.10
Codename:       karmic

Imagem de falha: link

Referências: link link

    

Answer 1

Todos os três modos de registro de dados devem deixar o próprio sistema de arquivos intacto após uma falha de energia. Por isso, deve sempre montar sem erros. A diferença é apenas nos dados dos seus arquivos; O modo data=writeback pode deixar dados obsoletos (ou seja, o que foi armazenado nos setores do disco antes das gravações feitas pelo aplicativo). data=ordered e data=journaled não devem fazer isso.

O mais provável é que as barreiras de E / S não estejam funcionando em sua configuração. Primeiro, verifique se você não está montando com barrier=0 / nobarrier . Isso aumenta o desempenho, mas causará danos na falta de energia.

Se as barreiras de E / S estiverem ativadas, também é possível que você esteja passando por uma camada de armazenamento que não as suporta. Em versões mais antigas, o LVM não e vários níveis do mdraid não. (Isso foi corrigido no Linux 2.6.33; portanto, somente se você estiver executando o Lucid ainda).

Finalmente, é possível que seus discos estejam contando mentiras. Os discos têm caches de gravação. Especialmente com o NCQ, eles ^{só dizem ao sistema operacional que eles gravaram dados quando eles realmente o fizeram, mas eles são conhecidos por dizer ao SO que estão escritos quando são apenas no cache de gravação do disco. Aumenta o desempenho. Pelo menos enquanto a energia permanecer ligada. Você pode tentar desabilitar o cache de gravação nos discos, mas você terá um impacto no desempenho.}

Note também que os discos de memória flash têm muito trabalho a fazer, e muitos deles não lidam bem com falhas de energia. (Por exemplo, o uso de nivelamento às vezes requer que um bloco de dados cheio de flash seja movido. Se a energia falhar no meio, coisas ruins acontecem em alguns discos flash.)

Finalmente ... você já considerou um no-break?