La respuesta breve cambió a medida que la comunidad probaba ZimaOS
Las primeras respuestas trataban ZimaOS como un sistema minimalista de estilo dispositivo, sin un gestor de paquetes tradicional. Recomendaban no dar por hecho que apt install o las modificaciones permanentes del sistema operativo base estarían disponibles. Se propusieron Docker y una máquina virtual con Debian o Ubuntu como límites de aislamiento más limpios.
Las comprobaciones prácticas posteriores añadieron una corrección importante: un participante encontró /usr/bin/mergerfs y mergerfs-fusermount ya presentes en un ZimaCube, mientras que no se encontró ningún binario de SnapRAID. Otro participante identificó que el mergerfs incluido era una versión antigua durante la depuración de una carrera de arranque. El resultado no fue «la instalación nativa es imposible», sino «los cambios manuales en el host no son compatibles oficialmente y dependen de la versión».
Los binarios manuales funcionaban, pero implicaban riesgos con las actualizaciones
Un usuario compiló ejecutables en WSL2, los copió a ZimaOS e informó de una configuración funcional con dos discos de datos y uno de paridad. El mantenedor de mergerfs señaló que las compilaciones estáticas pueden simplificar la implementación manual, pero que el comportamiento del contenedor depende de que el entorno de ejecución tenga privilegios root suficientes para exponer el montaje FUSE según sea necesario.
Las respuestas de la comunidad advirtieron repetidamente que copiar binarios en un sistema de estilo inmutable genera trabajo de mantenimiento. Las actualizaciones OTA pueden reemplazar o entrar en conflicto con los cambios manuales, y las instrucciones de Linux generadas por IA contenían errores durante los experimentos del usuario.
La comunidad creó una capa systemd-sysext
Después, un colaborador publicó un proyecto comunitario systemd-sysext para ZimaOS. Su objetivo era añadir mergerfs y SnapRAID como una capa de extensión independiente, en lugar de modificar directamente el sistema base de solo lectura.
Una prueba controlada en un ZimaCube Pro confirmó que la capa se cargaba, exponía mergerfs 2.42.0 y SnapRAID 14.5, y podía montar un conjunto mergerfs desechable. El evaluador creó un archivo a través de la ruta agrupada y verificó que apareciera en la rama subyacente antes de desmontarla correctamente.
La prueba no incluyó un ejercicio completo de paridad y recuperación con SnapRAID. El evaluador también deshabilitó los temporizadores y servicios predeterminados antes de configurar nada, para evitar que actuaran accidentalmente sobre discos reales.
Se encontraron y corrigieron dos carreras de arranque
Después de reiniciar, un usuario descubrió que el conjunto a veces fallaba, aunque un inicio manual posterior funcionaba. El autor de la extensión identificó dos carreras independientes. En primer lugar, la protección original detectaba el binario antiguo de mergerfs proporcionado por el sistema operativo base e iniciaba el conjunto antes de que se fusionara el binario más reciente de la extensión. La protección revisada comprobaba la presencia de SnapRAID, que solo proporcionaba la extensión.
En segundo lugar, mergerfs podía devolver un resultado correcto antes de que se montaran los discos físicos de las ramas, lo que producía un conjunto vacío que ocultaba el almacenamiento que llegaba después. Un simple bucle con Restart=on-failure no podía detectar ese estado exitoso pero vacío. El proyecto añadió comprobaciones explícitas que esperan a que se monte cada rama y se niegan a crear el conjunto si falta alguna.
El autor informó de una verificación tras un reinicio en frío en ZimaOS 1.6.1 después de estos cambios. Un usuario con una carcasa TerraMaster de cuatro discos también informó de que el conjunto terminó apareciendo después de que los discos tardaran cerca de un minuto en montarse.
La seguridad de SnapRAID aún requiere revisión por parte del operador
La extensión incluía un umbral de eliminación destinado a detener la sincronización después de un número inesperadamente elevado de eliminaciones. Posteriormente, un usuario preguntó cómo anular ese umbral tras eliminar deliberadamente miles de archivos. El hilo no resolvió esa cuestión operativa.
Cualquiera que evalúe el proyecto debe revisar las rutas de las ramas, las rutas de paridad, los temporizadores, los umbrales de eliminación y la ubicación de los datos de las aplicaciones antes de activar trabajos automatizados. Una comprobación correcta del binario o un montaje mergerfs no demuestran que se haya probado la recuperación de paridad con un conjunto de datos de producción.
Límite de compatibilidad
Se trata de una integración avanzada creada por la comunidad, no de una función de almacenamiento de ZimaOS compatible con IceWhale. Docker, una máquina virtual Linux completa, los binarios estáticos y sysext tienen diferentes características de privilegios y persistencia. El resultado más sólido del hilo es el método de extensión probado, pero aun así debe evaluarse con almacenamiento desechable antes de introducir datos reales.
Preguntas frecuentes
¿Mergerfs ya está incluido en ZimaOS?
Un participante verificó la presencia de un binario de mergerfs en su ZimaCube. Más tarde, el hilo identificó que esa copia base era una versión antigua, por lo que su presencia no garantiza la compatibilidad con una configuración moderna.
¿Se probó completamente la recuperación de SnapRAID?
No. La prueba controlada verificó la instalación y un conjunto mergerfs desechable, pero se detuvo explícitamente antes de realizar una prueba completa de paridad y restauración con SnapRAID.
¿Por qué no bastaba con esperar a que fallara un servicio?
Una de las carreras podía producir un conjunto vacío con un código de salida correcto. Como no se consideraba un fallo, una regla basada únicamente en reiniciar tras un error podía no detectarlo.
