¿Es posible reducir la matriz de software raid5 de forma segura?

Question

¿Es posible reducir el sistema de archivos ext4 y la matriz raid5 subyacente de forma segura?

Me gustaría reducir mi matriz raid de 15 TB/6 unidades que contiene un sistema de archivos ext4.

Antes de hacer eso en un sistema en vivo, decidí probarlo en un entorno de prueba. Escribí un script que simula el ciclo de vida del sistema de archivos raid+ (ensamblaje, mkfs, resize2fs, encogimiento, ...) pero en algunos casos corrompe el sistema de archivos. El script se ejecutó en dos distribuciones diferentes (una de ellas era Centos-8).

Intenté comprender las fallas y, a menos que me esté perdiendo algo, mdadm, durante el proceso de reducción de raid (mdadm --grow) no sabe nada sobre el sistema de archivos ext4 y parece que no es posible ayudar a que esta herramienta se comporte correctamente.

En mi escenario, un script para simula un proceso:

1. selecciona un número aleatorionum_dispositivosSe elige (entre 5 y 10): eso determina la cantidad de dispositivos en nuestra matriz de prueba.
2. selecciona un número aleatoriotamaño_dispositivo(entre 300 y 350) - tamaño (en MiB) de un solo dispositivo
3. crea y ensambla/dev/md0- una matriz RAID 5 (en mi caso fueron 0,90 metadatos) - el tamaño de una matriz estamaño_matriz=($num_dispositivos-1)*$tamaño_dispositivo
4. crea el sistema de archivos ext4 en/dev/md0y lo monta en/mnt
5. copia un archivo de referencia (en mi caso fue una de las imágenes del kernel de /boot)$num_dispositivosveces para/mnt(para tener algunos datos para validar la integridad del sistema de archivos): el sistema de archivos tiene aproximadamente el 80% del espacio libre disponible

6. el sistema de archivos se desmonta, se fscked ( e2fsck -f) luego se reduce (ya sea resize2fs -Mpara el tamaño mínimo o reisze2fs /dev/md0 {calculated_size}) y se fscked nuevamente

7. el script espera a que finalice el proceso de reconstrucción de mdadm (mirando /proc/mdstat)

8. Se calcula el nuevo tamaño de la matriz:new_array_size=($num_dispositivos-2)*$tamaño_dispositivo
9. El fallo del disco duro se simula mdadm --manage /dev/md0 --fail /dev/loop3seguido de mdadm --manage /dev/md0 --remove /dev/loop3
10. espera a que termine el proceso de remodelación

Una vez finalizado el proceso de remodelación, /dev/loop3 se marca como eliminado y otro dispositivo de bucle (por ejemplo, /dev/loop2) se marca como repuesto.

11. el proceso determina el repuesto y lo vuelve a agregar a una matriz ( mdadm --manage /dev/md0 --remove /dev/loop2seguido de mdadm --manage /dev/md0 --add /dev/loop2)
12. El script espera a que finalice la reconstrucción de la incursión (observando /proc/mdstat)

En este momento ocurre lo corrupto:

13. El sistema de archivos se monta nuevamente en /mnt.
14. La comparación de suma de comprobación md5 entre el archivo de referencia y las copias en un sistema de archivos reducido tiene éxito o falla para 1-2 archivos
15. el sistema de archivos se desmonta, se fscked ( e2fsck -f), se aumenta al máximo (resize2fs) y se fscked nuevamente
16. La corrupción sigue presente.

¿Estoy haciendo algo mal o el proceso de reducción de raid5 realmente no es compatible? ¿O son 0,90 metadatos el motivo?