O sistema garantirá que o mdadm seja sincronizado antes de concluir a reinicialização?

Question

Esta é uma continuação do meu problema louco do mdadm . Eu estou tentando descobrir o que pode ter causado sda para sair de sincronia em primeiro lugar. A única coisa que posso pensar é que eu tinha acabado de executar um monte de atualizações e estava reiniciando para recarregar a atualização do kernel. É possível que as duas unidades não tenham sido sincronizadas? O sistema impediria uma reinicialização se houvesse sincronização de mdadm? poderia ser feito para? Quaisquer outras sugestões sobre o que poderia ter acontecido? e como isso poderia ser evitado no futuro. Nada parece estar errado com a unidade.

    

Answer 1

Isso ocorre em um desligamento normal:

• O FAQ do mdadm do Debian implica que o kernel faz a coisa certa:

  ​8. (One of) my RAID arrays is busy and cannot be stopped. What gives?
  It is perfectly normal for mdadm to report the array with the root filesystem to be busy on shutdown. The reason for this is that the root filesystem must be mounted to be able to stop the array (or otherwise /sbin/mdadm does not exist), but to stop the array, the root filesystem cannot be mounted. Catch 22. The kernel actually stops the array just before halting, so it's all well.

• O driver md define todos os dispositivos como somente leitura no desligamento (e até dá aos dispositivos físicos cerca de um segundo para resolver).

Mesmo que o seu sistema trave no meio de uma gravação, o driver toma o cuidado de marcar os blocos como sujos enquanto estão sendo gravados e de ressincronizar os blocos sujos se ele for iniciado a partir de um array não limpo. Veja os comentários sobre os estados da matriz . A documentação do kernel avisa que os arrays estão sujos (não são limpos) e degradados (faltando peças) ) não são montados automaticamente, pois isso não seria seguro. Quando você monta um array sujo, você (possivelmente muito brevemente) o verá resync in /sys/block/md99/md/rd0/state . Tudo somado, o driver md cuida de proteger seus dados contra uma falha total de um componente de hardware (CPU ou disco), que é o que se espera dele.

O que md não irá protegê-lo é a corrupção de dados devido a uma falha bizantina (ou seja, inversão silenciosa de um ou mais bits) na RAM, na CPU, na placa-mãe ou no disco. O hardware do disco tem somas de verificação, mas elas não são perfeitas (veja, por exemplo, literatura promocional do Zfs ). Zfs e Btrfs pode proteger contra corrupção do dispositivo de armazenamento. A árvore de checksum do Btrfs garante que você será notificado se o seu disco rígido virar um pouco. O Zfs oferece uma opção de soma de verificação (de acordo com Blog de Jeff Bonwick ), até SHA-256, que protege não apenas contra corrupção aleatória, mas mesmo contra ataques deliberados, ao custo de ciclos de CPU.

    

Answer 2

Você criou o raid1 antes de colocar um sistema de arquivos nele? Se não - você reduziu o sistema de arquivos antes de torná-lo um dispositivo de invasão?

Se você não o resultado pode ser um superbloco ruim no seu raid-device.