Como o mdadm sabe onde as mudanças ocorreram?

2

Cerca de 10 dias atrás, meu RAID 1 gerenciado com o mdadm teve uma falha. O array é composto por 2 discos rígidos externos de 2 TB que são conectados via USB e eu suspeito que houve uma conexão solta que levou a uma falha.

De acordo com meu histórico bash, eu digitei estes comandos:

sudo mdadm --manage /dev/md1 --fail /dev/sda1
sudo mdadm --manage /dev/md1 --remove /dev/sda1
cat /proc/mdstat
sudo mdadm --manage /dev/md1 --add /dev/sda1
cat /proc/mdstat
mailx
cat /proc/mdstat

Encontrei instruções para isso on-line, mas iirc, o primeiro e / ou segundo comando falhou porque /dev/sda1 já não fazia parte da matriz ou algo assim.

Os dados definitivamente foram gravados no sistema de arquivos da matriz entre a falha e o ponto em que eu inseri os comandos acima.

Eu assumi que o mdadm iria copiar todos os dados de /dev/sdb1 para /dev/sda1 depois que eu emiti o quarto comando, o que levaria algum tempo. No entanto, quando eu chequei de volta na última linha depois de alguns minutos, já estava pronto.

Não sabendo como ele conseguiu aparentemente apenas copiar os dados alterados, eu temi pela integridade dos dados armazenados no meu RAID e sha256summed /dev/sda1 e /dev/sdb1 exceto os primeiros 128 MiB porque eu sei o primeiro 128 MiB são diferentes. Acontece que o resto dos discos armazenam exatamente os mesmos dados respectivamente, então o mdadm realmente restaurou a integridade do array.

Como ele sabia quais partes mudaram? Ainda teria funcionado se eu tivesse reiniciado entre o momento em que a falha ocorreu e o momento em que eu emiti os comandos acima?

    
por UTF-8 17.09.2017 / 19:13

1 resposta

1

cat /proc/mdstat deve mostrar a você que o respectivo RAID possui um bitmap. Isso é semelhante ao diário de um sistema de arquivos: Quando o sistema trava (ou o RAID quebra), a função de sincronização tem um local onde ele pode verificar quais dados podem ser danificados. Tudo o mais pode ser ignorado. Assim, a reconstrução é muito rápida.

significado da linha de bitmap

de link

bitmap: 0/10 pages [0KB], 16384KB chunk

What would it mean when it's, eg: 23/234

This refers to the in-memory bitmap (basically a cache of what's in the on-disk bitmap − it allows bitmap operations to be more efficient).

If it's 23/234 that means there are 23 of 234 pages allocated in the in-memory bitmap. The pages are allocated on demand, and get freed when they're empty (all zeroes). The in-memory bitmap uses 16 bits for each bitmap chunk to count all ongoing writes to the chunk, so it's actually up to 16 times larger than the on-disk bitmap.

    
por 17.09.2017 / 19:26