La réponse courte a changé à mesure que la communauté testait ZimaOS
Les premières réponses considéraient ZimaOS comme un système minimal de type appliance, sans gestionnaire de paquets traditionnel. Elles déconseillaient de supposer que apt install ou les modifications permanentes du système de base seraient disponibles. Docker ainsi qu'une machine virtuelle Debian ou Ubuntu étaient proposés comme des limites d'isolation plus propres.
Des vérifications pratiques ultérieures ont apporté une correction importante : un participant a trouvé /usr/bin/mergerfs et mergerfs-fusermount déjà présents sur un ZimaCube, tandis qu'aucun binaire SnapRAID n'a été trouvé. Un autre participant a identifié que le mergerfs fourni était une version ancienne lors du débogage d'une course au démarrage. La conclusion n'était donc pas « l'installation native est impossible », mais plutôt « les modifications manuelles de l'hôte ne sont pas prises en charge et dépendent de la version ».
Les binaires manuels fonctionnaient, mais comportaient un risque lors des mises à jour
Un utilisateur a compilé des exécutables dans WSL2, les a copiés sur ZimaOS et a indiqué avoir obtenu une configuration fonctionnelle avec deux disques de données et un disque de parité. Le mainteneur de mergerfs a précisé que les compilations statiques peuvent simplifier le déploiement manuel, mais que le comportement dans un conteneur dépend du fait que l'environnement d'exécution dispose de privilèges root suffisants pour exposer le montage FUSE comme requis.
Les réponses de la communauté ont averti à plusieurs reprises que la copie de binaires dans un système de type immuable crée une charge de maintenance. Les mises à jour OTA peuvent remplacer ou entrer en conflit avec les modifications manuelles, et les instructions Linux générées par l'IA comportaient des erreurs pendant les expérimentations de l'utilisateur.
La communauté a créé une couche systemd-sysext
Un contributeur a ensuite publié un projet systemd-sysext communautaire pour ZimaOS. Son objectif était d'ajouter mergerfs et SnapRAID sous forme de couche d'extension distincte, plutôt que de modifier directement le système de base en lecture seule.
Un test contrôlé sur un ZimaCube Pro a confirmé que la couche se chargeait, exposait mergerfs 2.42.0 et SnapRAID 14.5, et pouvait monter un pool mergerfs temporaire. Le testeur a créé un fichier via le chemin du pool et a vérifié qu'il apparaissait sur la branche sous-jacente avant de démonter proprement le pool.
Ce test n'incluait pas d'exercice complet de parité et de récupération avec SnapRAID. Le testeur a également désactivé les minuteurs et services par défaut avant toute configuration afin qu'ils ne puissent pas agir accidentellement sur des disques réels.
Deux courses au démarrage ont été découvertes et corrigées
Après un redémarrage, un utilisateur a constaté que le pool échouait parfois, alors qu'un démarrage manuel ultérieur réussissait. L'auteur de l'extension a identifié deux courses distinctes. Premièrement, la protection d'origine détectait l'ancien binaire mergerfs fourni par le système de base et démarrait le pool avant que le binaire plus récent de l'extension ne soit fusionné. La protection révisée vérifiait la présence de SnapRAID, fourni uniquement par l'extension.
Deuxièmement, mergerfs pouvait renvoyer un succès avant le montage des disques physiques des branches, ce qui produisait un pool vide masquant le stockage arrivé ultérieurement. Une simple boucle Restart=on-failure ne pouvait pas détecter cet état réussi mais vide. Le projet a ajouté des vérifications explicites qui attendent le montage de chaque branche et refusent de créer le pool lorsqu'une branche est absente.
L'auteur a signalé une vérification après redémarrage à froid sur ZimaOS 1.6.1 après ces changements. Un utilisateur disposant également d'un boîtier TerraMaster à quatre disques a indiqué que le pool était finalement apparu après que les disques eurent mis près d'une minute à se monter.
La sécurité de SnapRAID nécessite toujours une vérification par l'opérateur
L'extension incluait un seuil de suppression destiné à interrompre la synchronisation après un nombre de suppressions exceptionnellement élevé. Un utilisateur ultérieur a demandé comment contourner ce seuil après avoir supprimé volontairement des milliers de fichiers. La discussion n'a pas répondu à cette question opérationnelle.
Toute personne évaluant le projet doit vérifier les chemins des branches, les chemins de parité, les minuteurs, les seuils de suppression et l'emplacement des données des applications avant d'activer les tâches automatisées. La vérification réussie d'un binaire ou le montage réussi de mergerfs ne prouvent pas que la récupération de parité a été testée sur un jeu de données de production.
Limites de la prise en charge
Il s'agit d'une intégration avancée créée par la communauté, et non d'une fonctionnalité de stockage ZimaOS prise en charge par IceWhale. Docker, une machine virtuelle Linux complète, les binaires statiques et sysext présentent chacun des caractéristiques différentes en matière de privilèges et de persistance. Le résultat le plus solide de la discussion est la méthode d'extension testée, mais elle doit tout de même être évaluée sur un stockage temporaire avant d'y introduire des données réelles.
FAQ
mergerfs est-il déjà inclus dans ZimaOS ?
Un participant a vérifié la présence d'un binaire mergerfs sur son ZimaCube. La discussion a ensuite établi que cette copie du système de base était une version ancienne ; sa présence ne garantit donc pas la compatibilité avec une configuration moderne.
La récupération SnapRAID a-t-elle été entièrement testée ?
Non. Le test contrôlé a vérifié l'installation et un pool mergerfs temporaire, mais s'est explicitement arrêté avant un test complet de parité et de restauration SnapRAID.
Pourquoi attendre l'échec d'un service ne suffisait-il pas ?
Une des courses pouvait produire un pool vide avec un code de sortie indiquant une réussite. Comme il ne s'agissait pas d'un échec, une règle Restart=on-failure seule pouvait ne pas le détecter.
