Resiliência do Btrfs dentro do RAID5

Question

O Btrfs atualmente carece de fsck, arriscando a corrupção se houver uma falha de energia. Até que ponto, se de alguma forma, criar um sistema de arquivos btrfs dentro de um array RAID5 atenuaria isso?

    

Answer 1

AFAIK não faria diferença.

O RAID é uma camada de abstração para discos físicos, faz com que vários discos / partições pareçam um único "dispositivo de bloco" para o sistema de arquivos. Alguns níveis de RAID (incluindo RAID1 e RAID5) podem lidar com falhas de disco físico de forma transparente: Remova um disco e, para o sistema de arquivos, parece que nada mudou.

Mas o sistema de arquivos funciona na camada de abstração "dispositivo de bloco". Usar um RAID5 como dispositivo de bloco ajuda a lidar com falhas de disco físico, mas não faz nada para o próprio sistema de arquivos, portanto, o risco de corrupção do sistema de arquivos permanece o mesmo.

Os blocos RAID (mdadm 'chunks' com tamanho padrão 64kB) diferem dos blocos do sistema de arquivos (tamanho padrão 4kB ext4) e são projetados para detectar um tipo diferente de corrupção.

O RAID5 funciona dividindo os dados do sistema de arquivos e gravando um trecho para cada um dos discos N-1 e uma soma de verificação para o enésimo disco. O RAID5 é projetado para detectar "dados corrompidos" no sentido de setores defeituosos, em cujo caso o original pode ser restaurado a partir da soma de verificação e os N-2 restantes bons blocos.

Mas se o FS atualiza os metadados e morre antes que tenha tempo de gravar os arquivos, o sistema de arquivos pode estar corrompido sem que o RAID seja mais sábio: o que foi gravado em disco é o mesmo do que é lido do disco, como evidenciado pela correspondência de checksums. O RAID não pode saber que partes importantes estão faltando na perspectiva de um aplicativo de nível mais alto.

Veja este documento (pdf) para ver exemplos de corrupção que passam despercebidas por RAID. No contexto da corrupção do sistema de arquivos, eu acho que "gravações rasgadas" (apenas alguns dos dados que deveriam estar escritos são) é particularmente relevante.

    

Answer 2

O software Linux RAID5 na verdade pioraria a situação de falha de energia - muito pior - pelo motivo já abordado. Mesmo no ext3 / 4, a repetição do diário após uma falha de energia não corrigirá a inconsistência do RAID5, que invariavelmente ocorre devido ao software RAID não ter um "diário" não volátil para reproduzir. O resultado é a corrupção não apenas dos dados do usuário, mas também dos dados do sistema de arquivos no caso de uma falha de energia durante uma operação de gravação. Controladores RAID de hardware dedicado com cache de bateria não sofrem com isso, mas isso ainda não compensa a falta de capacidade de executar o fsck no btrfs.

Se você se preocupa com a integridade dos seus dados, não execute o btrfs sem uma ferramenta fsck e não execute o RAID5 (ou qualquer nível de RAID de paridade) sem o cache não volátil ou um no-break.

    

Answer 3

Quando um disco de RAID5 / 6 falha, todo o subsistema de E / S fica temporariamente travado quando o kernel tenta obter controle sobre a unidade com falha, redefinindo o barramento SATA ou a unidade. O atraso pode levar dezenas de segundos, que de alguma forma afetam o BTRFS para ficar corrompido, além da recuperação.

Veja que a falha no disco do MDRAID causa um erro no kernel do BTRFS .