La fuente demuestra que reemplazar ambos miembros de un RAID 1 por discos más grandes no amplía automáticamente el sistema de archivos utilizable. Un usuario reemplazó correctamente dos discos de 500 GB por discos de 1 TB, uno a la vez, y dejó que ZimaOS reconstruyera la matriz después de cada cambio. En ese momento, ambos miembros físicos tenían 1 TB, pero la matriz, el dispositivo RAID y el sistema de archivos Btrfs seguían exponiendo únicamente la capacidad anterior de 500 GB.
En ZimaOS+ 1.5.4, ese usuario completó la ampliación mediante SSH con mdadm --grow /dev/md0 --size=max, esperaron a que se produjera la recuperación o resincronización correspondiente y, por último, ejecutaron btrfs filesystem resize max en el sistema de archivos montado. Informaron que la interfaz gráfica y df y después mostró la capacidad mayor. Esta es una sólida verificación de la comunidad, pero sigue siendo un flujo de trabajo manual mediante la CLI, no un procedimiento actual de la interfaz gráfica de IceWhale.
Haz una copia de seguridad antes de iniciar una ampliación de capacidad
RAID 1 protege contra el fallo de un miembro; no protege contra errores del operador, daños en los metadatos de la matriz, errores del sistema de archivos ni problemas con un segundo disco durante la reconstrucción.
Reemplaza solo un miembro del RAID cada vez
- apaga el sistema;
- reemplaza el primer disco antiguo por el disco más grande;
- inicia el sistema;
- usa la recuperación de ZimaOS para reconstruirla;
- espera hasta que la recuperación haya terminado por completo.
Repite el proceso con el segundo miembro
Solo después de que se completó la primera reconstrucción, el usuario apagó el sistema y reemplazó el segundo disco; después volvió a ejecutar la recuperación mediante la interfaz gráfica y esperó a que terminara por completo.
En esta etapa, la matriz estaba sana con dos dispositivos físicos más grandes, pero seguía teniendo el tamaño histórico de los miembros.
A continuación, el usuario de la comunidad amplió la matriz mdadm
El comando original era:
sudo mdadm --grow /dev/md0 --size=maxVerificaron la nueva geometría de la matriz con mdadm --detail y esperó a que se completara el nuevo estado de recuperación o resincronización.
Nunca des por sentado que tu matriz es /dev/md0; identifica primero la matriz real.
Después hubo que ampliar el sistema de archivos Btrfs
El proceso original terminó con:
sudo btrfs filesystem resize max /your/mounted/filesystemUsa la ruta real del sistema de archivos Btrfs montado en lugar de copiar literalmente el marcador de posición.
Por qué fueron necesarios dos pasos de redimensionamiento
- el dispositivo RAID de Linux md;
- el sistema de archivos Btrfs que se encuentra encima.
Ambos deben exponer el tamaño mayor antes de que los usuarios vean la capacidad adicional.
Trata esto como un procedimiento comunitario específico de la versión
El usuario de la fuente ejecutó explícitamente ZimaOS+ 1.5.4. El ZimaOS actual es más reciente y el comportamiento de la gestión del almacenamiento puede cambiar. Antes de ejecutar un procedimiento manual mdadm --grow en el almacenamiento de producción, verifica que la interfaz siga sin ofrecer una ruta de ampliación compatible y considera solicitar a soporte de IceWhale el procedimiento actual.
Verifica el estado del RAID antes de cada cambio físico
Antes de reemplazar el primer disco —y nuevamente antes de reemplazar el segundo— confirma que la matriz esté en buen estado y completamente sincronizada. Iniciar el segundo reemplazo mientras la primera reconstrucción está incompleta elimina la redundancia en la que dependes durante la ampliación.
Registra los números de serie de los miembros para que el disco físico que retires coincida con el miembro lógico mostrado por ZimaOS.
Los discos de reemplazo necesitan suficiente capacidad real
Los discos con capacidades nominalmente iguales pueden diferir ligeramente en el número de sectores utilizables. La ampliación más segura utiliza discos de reemplazo que sean claramente más grandes que los miembros antiguos y, como mínimo, igual de grandes entre sí.
Si el segundo disco de «1 TB» es ligeramente más pequeño que el primero, es posible que el paso de ampliación o reconstrucción de md no se comporte como se espera.
Espera más de un ciclo de resincronización
El flujo de trabajo de la fuente reconstruyó la matriz después del primer reemplazo físico, volvió a reconstruirla después del segundo y luego entró en otro estado de recuperación o resincronización después de mdadm --grow. Eso significa que una ampliación de capacidad puede tardar considerablemente más que simplemente cambiar dos discos.
Mantén el NAS conectado a una fuente de alimentación fiable y evita reinicios innecesarios durante cada fase de recuperación.
Verifica el dispositivo de bloques y el sistema de archivos al final
Después del cambio de tamaño final de Btrfs, verifica el resultado en más de una capa:
-
mdadm --detail— geometría del RAID md; -
df -ho las herramientas del sistema de archivos Btrfs: capacidad utilizable del sistema de archivos; - Interfaz de almacenamiento de ZimaOS: tamaño esperado del grupo y estado correcto.
Si una capa todavía muestra el tamaño anterior, detente e investiga en lugar de repetir los comandos de ampliación a ciegas.
Preguntas frecuentes sobre la ampliación de RAID 1
¿Puede un disco más grande aumentar inmediatamente la capacidad de RAID1?
No. El espejo sigue limitado por el miembro más pequeño y por la geometría histórica de la matriz.
¿Reemplazar ambos discos más pequeños aumentó automáticamente la capacidad en la fuente?
No. El usuario aún tuvo que ampliar la matriz md y luego cambiar el tamaño de Btrfs.
¿Se confirmó la fuente del flujo de ampliación manual?
Sí, por parte de un usuario de ZimaOS+ 1.5.4. No se publicó como un procedimiento oficial de IceWhale.
