É possível reduzir a matriz de software raid5 de maneira segura?

Question

É possível reduzir o sistema de arquivos ext4 e o array raid5 subjacente de maneira segura?

Gostaria de reduzir meu array raid de 15 TB/6 unidades que contém um sistema de arquivos ext4.

Antes de fazer isso no sistema live, decidi experimentá-lo em um ambiente de teste. Eu escrevi um script que simula o ciclo de vida do sistema de arquivos raid + (montagem, mkfs, resize2fs, redução, ...), mas em alguns casos ele corrompe o sistema de arquivos. O script foi executado em duas distros diferentes (uma delas era Centos-8).

Tentei entender as falhas e, a menos que esteja faltando alguma coisa, mdadm, durante o processo de redução do ataque (mdadm --grow) não sabe nada sobre o sistema de arquivos ext4 e parece que não é possível ajudar esta ferramenta a se comportar corretamente.

No meu cenário, um script para simular um processo:

1. seleciona um número aleatórionum_dispositivos(entre 5 e 10) é escolhido - isso determina o número de dispositivos em nossa matriz de teste
2. seleciona um número aleatóriotamanho_do_dispositivo(entre 300 e 350) – tamanho (em MiB) de um único dispositivo
3. cria e monta/dev/md0- uma matriz RAID 5 (no meu caso eram 0,90 metadados) - o tamanho de uma matriz éarray_size=($num_devices-1)*$device_size
4. cria sistema de arquivos ext4 em/dev/md0e monta-o em/mnt
5. copia um arquivo de referência (no meu caso era uma das imagens do kernel de/boot)$num_dispositivosvezes para/mnt(para ter alguns dados para validar a integridade do sistema de arquivos) - o sistema de arquivos tem cerca de 80% de espaço livre disponível

6. o sistema de arquivos é desmontado, fscked ( e2fsck -f), depois reduzido ( resize2fs -Mpara tamanho mínimo ou reisze2fs /dev/md0 {calculated_size}) e fscked novamente

7. o script aguarda a conclusão do processo de reconstrução do mdadm (observando /proc/mdstat)

8. o novo tamanho da matriz é calculado:new_array_size=($num_devices-2)*$device_size
9. falha no disco rígido é simulada por mdadm --manage /dev/md0 --fail /dev/loop3seguida por mdadm --manage /dev/md0 --remove /dev/loop3
10. espera que o processo de remodelação termine

Assim que o processo de remodelação for concluído, /dev/loop3 é marcado como removido e outro dispositivo de loop (por exemplo, /dev/loop2) é marcado como sobressalente.

11. o processo determina o sobressalente e o adiciona novamente a uma matriz ( mdadm --manage /dev/md0 --remove /dev/loop2seguido por mdadm --manage /dev/md0 --add /dev/loop2)
12. script aguarda a reconstrução do ataque para terminar (assistindo /proc/mdstat)

Neste momento ocorre o corrupto:

13. o sistema de arquivos é montado novamente em /mnt
14. A comparação da soma de verificação md5 entre o arquivo de referência e as cópias em um sistema de arquivos reduzido é bem-sucedida ou falha para 1-2 arquivos
15. o sistema de arquivos é desmontado, fscked ( e2fsck -f), aumentado para o máximo (resize2fs) e fscked novamente
16. a corrupção ainda está presente

Estou fazendo algo errado ou o processo de redução do raid5 realmente não é compatível? ou os metadados 0,90 são o motivo?