Principais problemas com fsck de 10TB ext3 RAID 6 (alocação de memória falhou, etc.)

Question

Eu adicionei recentemente um 7th drive de 2TB a uma configuração de software RAID 6 do Linux. Depois que o md terminou de remodelar o array de 6 para 7 unidades (de 8 para 10 TB), eu ainda consegui montar o sistema de arquivos sem problemas. Na preparação para resize2fs, desmontei a partição e executei fsck -Cfyv e fui saudado com um fluxo interminável de milhões de erros aleatórios. Aqui está um pequeno trecho:

Pass 1: Checking inodes, blocks, and sizes
Inode 4193823 is too big.  Truncate? yes
Block #1 (748971705) causes symlink to be too big.  CLEARED.
Block #2 (1076864997) causes symlink to be too big.  CLEARED.
Block #3 (172764063) causes symlink to be too big.  CLEARED.
...
Inode 4271831 has a extra size (39949) which is invalid Fix? yes
Inode 4271831 is in use, but has dtime set.  Fix? yes
Inode 4271831 has imagic flag set.  Clear? yes
Inode 4271831 has a extra size (8723) which is invalid Fix? yes
Inode 4271831 has EXTENTS_FL flag set on filesystem without extents support. Clear? yes
...
Inode 4427371 has compression flag set on filesystem without compression support. Clear? yes
Inode 4427371 has a bad extended attribute block 1242363527.  Clear? yes
Inode 4427371 has INDEX_FL flag set but is not a directory. Clear HTree index? yes
Inode 4427371, i_size is 7582975773853056983, should be 0.  Fix? yes
...
Inode 4556567, i_blocks is 5120, should be 5184.  Fix? yes
Inode 4566900, i_blocks is 5160, should be 5200.  Fix? yes
...
Inode 5628285 has illegal block(s).  Clear? yes
Illegal block #0 (4216391480) in inode 5628285.  CLEARED.
Illegal block #1 (2738385218) in inode 5628285.  CLEARED.
Illegal block #2 (2576491528) in inode 5628285.  CLEARED.
...
Illegal indirect block (2281966716) in inode 5628285.  CLEARED.
Illegal double indirect block (2578476333) in inode 5628285.  CLEARED.
Illegal block #477119515 (3531691799) in inode 5628285.  CLEARED.

Compressão? Extensões Eu nunca tive ext4 em qualquer lugar perto desta máquina!

Agora, o problema é que o fsck continua morrendo com a seguinte mensagem de erro:

Error storing directory block information (inode=5628285, block=0, num=316775570): Memory allocation failed

No começo, eu era capaz de simplesmente re-executar o fsck e ele iria morrer em um inode diferente, mas agora está resolvido em 5628285 e eu não consigo fazer isso ir além disso.

Passei os últimos dias tentando procurar correções e encontrei as 3 "soluções" a seguir:

• Use o Linux de 64 bits. /proc/cpuinfo contém lm como um processador flags , getconf LONG_BIT retorna 64 e uname -a tem isto a dizer: %código%. Deve ser tudo de bom, não?
• Adicione Linux <servername> 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux / [scratch_files] a directory = /var/cache/e2fsck . Isso e toda vez que eu executo novamente o fsck, ele adiciona outro arquivo de 500K /etc/e2fsck.conf e um de 8M *-dirinfo-* ao diretório *-icount-* . Então, isso parece ter o efeito desejado também.
• Adicione mais memória ou troque espaço para a máquina. 12GB de RAM e uma partição swap de 32GB devem ser suficientes, não?

Escusado será dizer: nada ajudou, caso contrário eu não estaria escrevendo aqui.

Naturalmente, agora a unidade está marcada como ruim e não consigo mais montá-la. Então, a partir de agora, eu perdi 8 TB de dados devido a uma verificação de disco?!?!?

Isso me deixa com 3 perguntas:

• Existe alguma coisa que eu possa fazer para consertar essa unidade (lembre-se, tudo estava bem antes de executar o fsck!) além de gastar um mês para aprender o formato do disco ext3 e tentar consertá-lo manualmente com um editor hexadecimal ???
• Como é possível que algo tão essencial ao fsck para um sistema de arquivos tão popular quanto o ext3 ainda tenha problemas como esse ??? Especialmente porque o ext3 tem mais de uma década.
• Existe uma alternativa ao ext3 que não tenha esses tipos de problemas fundamentais de confiabilidade? Talvez jfs?

(Estou usando o e2fsck 1.42.5 no Debian Wheezy 7.1 de 64 bits agora, mas tive os mesmos problemas com uma versão anterior do Debian Squeeze de 32 bits)

    

Answer 1

Depois de brincar com o fsck , encontrei alguns remédios:

Evitando o erro "Falha na alocação de memória"

fsck parece ter um grande problema com o vazamento de memória. Se ele for executado em um sistema de arquivos com alguns problemas (reais ou imaginários), ele irá "consertá-los" um a um (veja o dump de tela na pergunta original). Ao fazê-lo, consome mais e mais memória (talvez mantendo um log de alterações?). Praticamente sem limites. Mas, fsck pode ser cancelado a qualquer momento (Ctrl-C) e reiniciado. Nesse caso, ele continuará de onde parou, mas o uso da memória é redefinido para quase nada (por um tempo).

Com isso em mente, as três coisas que precisam ser feitas são:

• Use Linux de 64 bits (parece fazer diferença em como fsck pode usar a memória disponível)
• Adicione uma partição de swap ridiculamente grande (usei 256 GB, fsck é executado por aproximadamente 12 horas com ela)
• Freqüentemente abortar e reiniciar o fsck (com que frequência depende do tamanho da partição virtual)

OBSERVAÇÃO: Não tenho idéia se o cancelamento e a reinicialização do fsck trazem outros perigos (provavelmente), mas parece funcionar para mim.

Lidando com o dano resultante, se ocorrer o erro "Alocação de memória falhada" (IMPORTANTE!)

fsck lida com o erro Memory allocation failed da pior maneira possível: Eu destruo dados perfeitamente bons. Eu não tenho certeza do porquê, mas meu palpite é que ele faz algumas gravações finais de dados no disco das coisas que ele guardava na memória, que (devido ao erro) foram corrompidas.

No meu caso, o problema mais visível era que quando eu reiniciava fsck após o erro, algumas vezes ele reportava um super-bloco corrompido. O problema é: Eu não tenho idéia de como ele corrompeu o super-bloco, especialmente nos casos em que ele não o reportou como corrompido. Talvez, se reiniciado após o erro, ele use metadados de unidade incorretos encontrados no super-bloco corrompido para fazer todas as verificações adicionais e acabar corrigindo "problemas" que não estão realmente lá, destruindo bons dados no processo. / p>

Portanto, se fsck ever morrer com o erro Memory allocation failed , ele precisará ser reiniciado usando o parâmetro -b para usar um supercluster de backup que (esperançosamente) não foi corrompido pelo erro. A localização dos super-blocos de backup pode ser encontrada usando mke2fs -n /dev/... .

Como não sei o que acontece se fsck morre com o supercluster de backup selecionado, normalmente eu apenas aborto fsdk imediatamente quando chega em Pass 1: Checking inodes, blocks, and sizes e reinicio novamente sem -b , no qual ponto começa sem reclamar sobre um super-bloco ruim. Ou seja parece que a primeira coisa que o fsck -b faz é restaurar o superbloco principal.

Agora o que todos esperavam:

Como montar um sistema de arquivos sem permitir que o fsck seja executado até a conclusão

Isto, eu encontrei por acidente: Acontece que depois de executar fsck -b e abortar assim que ele imprime o Pass 1: Checking inodes, blocks, and sizes (antes de quaisquer erros serem encontrados) o sistema de arquivos é deixado em um estado montável (Yay Eu obtive praticamente todos os meus dados de volta!).

(Nota: pode haver outra maneira de usar mount -o force , mas não foi necessário no meu caso.)

Como evitar todos esses problemas em primeiro lugar

Parece haver duas maneiras:

• Use o ext3, mas mantenha um backup perfeitamente atualizado. Em seguida, execute frequentemente fsck com o parâmetro -N . Se ele mostra qualquer problemas, exclua todo o fs e restaure tudo do backup. Uma vez que, neste cenário, alguém estaria confiando muito no backup, sugiro manter um backup do backup. Além disso, use uma ferramenta de cópia que de alguma forma garanta que a restauração não crie erros aleatórios no processo (um MTBF de um trilhão de r / w-ops é pequeno quando se lida com TB de dados). Certifique-se de planejar o tempo de inatividade resultante também, já que uma restauração multi-TB provavelmente leva um tempo ...
• Minha recomendação: NÃO use o ext3! O design do fs e as ferramentas associadas (aqui fsck ) não são robustos o suficiente para uso real na produção (ainda?). A maneira como fsck lida com o erro de memória e o fato de que o erro ocorre em primeiro lugar não é aceitável em minha mente. Eu vou tentar o xfs a partir de agora, mas ainda não tenho experiência suficiente para dizer se está melhor.

Answer 2

Basta recriar o array e restaurar os dados de um backup. O objetivo do RAID é minimizar o tempo de inatividade. Ao mexer e tentar consertar um problema como esse, você aumenta seu tempo de inatividade, derrotando todo o propósito do RAID. O RAID não protege contra a perda de dados, protege contra o tempo de inatividade.

    

Answer 3

Infelizmente, não posso "adicionar um comentário", mas tive que gritar aqui e agradecer ao Op. Eu tive uma falha no RAID6 e montei manualmente 6 das 8 unidades com as contagens de eventos correspondentes. No entanto, não consegui mount o array montado.

Pareceu que eu precisava usar um Super-bloco de backup. A execução de fsck -b <location> ... acabou morrendo com falta de memória, o que me levou a esse tópico / questão.

Resumindo, usar fsck -b <location>... e, em seguida, fazer ctrl+c permitiu que eu montasse minha matriz e recuperasse meus arquivos.

Obrigado!