mdadm; trabalhando anteriormente; depois de "falha", não é possível unir matriz devido ao tamanho do disco

4

Resumo

Eu tinha um array Raid 5 funcional, reinicializei a caixa e, em seguida, o mdadm não pôde reabastecer uma parte.

Vendo que era apenas uma parte, achei que seria fácil apenas sincronizar novamente. Mas isso acabou não funcionando, porque aparentemente agora o dispositivo não é grande o suficiente para entrar no array!?

Configuração inicial do ataque

Infelizmente, é bastante complicado. Eu tenho um Raid 5 combinando dois discos de 3 TB com dois ataques lineares (consistindo de 1 TB + 2 TB). Eu não participo os discos, isto é, o ataque abrange discos físicos. Em retrospecto, isso é provavelmente o que causou a falha inicial.

Após a fatídica reinicialização

O mdadm se recusaria a montar um dos arrays lineares, alegando que não existia nenhum superbloco (verificando com mdadm --examine em ambos não retornou nada). Ainda mais estranho, aparentemente eles ainda tinham algumas partições de mesa sobre eles.

Neste ponto, achei que a solução mais rápida seria apenas recriar o array linear, adicioná-lo ao array raid5 maior e fazer com que ele fosse sincronizado novamente. Por isso, optei por remover apenas as entradas da tabela de partições, isto é: particioná-las no espaço livre. E então eu criei um array linear abrangendo ambos os discos.

# mdadm --create /dev/md2 --level=linear --raid-devices=2 /dev/sda /dev/sdc

No entanto, ao tentar adicioná-los de volta ao array, obtenho

# mdadm --add /dev/md0 /dev/md2        
mdadm: /dev/md2 not large enough to join array

Então, estou adivinhando corretamente que os discos encolheram?

Contando blocos

Eu acho que é hora de algumas contagens de blocos!

Os dois componentes da matriz linear:

RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0   1000204886016   /dev/sda
RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0   2000398934016   /dev/sdc

Se o modo linear do mdadm não tivesse sobrecarga, a soma dos dois tamanhos seria maior que uma das unidades de 3 TB (3000592982016). Mas esse não é o caso:

/ proc / mdstat relata que o array linear tem tamanho 2930015024, que é 120016 menor que o necessário

# mdadm --detail /dev/md0 | grep Dev\ Size
Used Dev Size : 2930135040 (2794.39 GiB 3000.46 GB)

Mas isso ... é terrivelmente suspeito! Antes de reiniciar (uma encarnação ainda que anterior) desta matriz linear fazia parte da matriz maior!

O que acredito acontecer

Após a reinicialização, o mdadm reconheceu que uma parte da matriz estava ausente. Como era o menor membro, o tamanho do dispositivo de matriz foi aumentado automaticamente para preencher o próximo dispositivo menor.

Mas isso não soa como um comportamento sensato, não é?

Uma alternativa seria que, por alguma razão, eu não esteja mais criando o raid linear de tamanho máximo, mas ... isso também é meio sem sentido.

O que eu tenho pensado em fazer

Reduza o array degradado para excluir o array linear "quebrado" e tente --add e --grow novamente. Mas receio que isso não altere o tamanho do dispositivo.

Como não entendo exatamente o que deu errado, prefiro primeiro entender o que causou esse problema antes de fazer qualquer coisa apressada.

    
por lukas 22.10.2013 / 00:10

1 resposta

3

So uh... I guess... well... the disks... shrank?

A área mdadm de reservas para metadados, por padrão, provavelmente cresceu ... Eu tive alguns casos recentemente em que mdadm desperdiçou 128MiB sem motivo aparente. Você deseja verificar mdadm --examine /dev/device* para a entrada data offset . Idealmente, não deveria haver mais de 2048 setores.

Se esse for realmente o problema, você pode usar mdadm --create juntamente com o parâmetro --data-offset= para tornar mdadm menos espaço para metadados.

Se isso ainda não for suficiente, você terá que tentar a sua sorte com os antigos 0.90 metadata (que podem ser os mais eficientes em termos de espaço, pois ele não usa esse deslocamento) ou encolher o outro lado do RAID. pouco (lembre-se de encolher o sistema de arquivos / LV primeiro).

    
por 22.10.2013 / 00:28