La risposta breve è cambiata con i test della community su ZimaOS
Le prime risposte descrivevano ZimaOS come un sistema minimale, simile a un appliance e privo di un gestore di pacchetti tradizionale. Sconsigliavano di presumere che apt install o modifiche permanenti al sistema operativo di base fossero disponibili. Docker e una macchina virtuale Debian o Ubuntu venivano proposti come confini di isolamento più puliti.
Le verifiche pratiche successive hanno aggiunto una correzione importante: un partecipante ha trovato /usr/bin/mergerfs e mergerfs-fusermount già presenti su uno ZimaCube, mentre non è stato trovato alcun binario SnapRAID. Un altro partecipante ha identificato il mergerfs incluso come una versione precedente durante il debug della gara di avvio. Il risultato non è stato «l'installazione nativa è impossibile», bensì «le modifiche manuali all'host non sono supportate e dipendono dalla versione».
I binari manuali funzionavano, ma comportavano rischi con gli aggiornamenti
Un utente ha compilato gli eseguibili in WSL2, li ha copiati su ZimaOS e ha riferito di aver ottenuto una configurazione funzionante con due dischi dati e un disco di parità. Il manutentore di mergerfs ha osservato che le build statiche possono semplificare la distribuzione manuale, ma il comportamento nei container dipende dal fatto che il runtime disponga di privilegi root sufficienti per esporre il mount FUSE come richiesto.
Le risposte della community hanno avvertito ripetutamente che copiare binari in un sistema di tipo immutabile crea lavoro di manutenzione. Gli aggiornamenti OTA possono sostituire o entrare in conflitto con le modifiche manuali, e le istruzioni Linux generate dall'IA contenevano errori durante gli esperimenti dell'utente.
La community ha creato un livello systemd-sysext
Un collaboratore ha quindi pubblicato un progetto systemd-sysext della community per ZimaOS. Lo scopo era aggiungere mergerfs e SnapRAID come livello di estensione separato, invece di modificare direttamente il sistema di base in sola lettura.
Un test controllato su ZimaCube Pro ha confermato che il livello veniva caricato, rendeva disponibili mergerfs 2.42.0 e SnapRAID 14.5 e consentiva di montare un pool mergerfs temporaneo. Il tester ha creato un file tramite il percorso del pool e ha verificato che apparisse sul ramo sottostante prima di smontare tutto correttamente.
Il test non includeva un'esercitazione completa di parità e ripristino con SnapRAID. Prima di configurare qualsiasi cosa, il tester ha inoltre disabilitato i timer e i servizi predefiniti, così che non potessero agire accidentalmente sui dischi reali.
Sono state individuate e corrette due gare di avvio
Dopo il riavvio, un utente ha riscontrato che il pool a volte non veniva avviato, mentre un avvio manuale successivo riusciva. L'autore dell'estensione ha identificato due gare separate. Innanzitutto, il controllo originale rilevava il vecchio binario mergerfs fornito dal sistema operativo di base e avviava il pool prima che il binario più recente dell'estensione fosse stato integrato. Il controllo aggiornato verificava la presenza di SnapRAID, fornito esclusivamente dall'estensione.
In secondo luogo, mergerfs poteva restituire un esito positivo prima che i dischi fisici dei rami fossero montati, producendo un pool vuoto che nascondeva lo storage in arrivo successivamente. Un semplice ciclo Restart=on-failure non poteva rilevare questo stato, che risultava positivo ma vuoto. Il progetto ha aggiunto controlli espliciti che attendono il mount di ogni ramo e impediscono di creare il pool se manca un ramo.
L'autore ha riferito di aver verificato il riavvio a freddo su ZimaOS 1.6.1 dopo queste modifiche. Un utente con un enclosure TerraMaster a quattro dischi ha inoltre riferito che il pool alla fine compariva dopo che i dischi avevano impiegato quasi un minuto per essere montati.
La sicurezza di SnapRAID richiede comunque una verifica da parte dell'operatore
L'estensione includeva una soglia di eliminazione pensata per interrompere la sincronizzazione dopo un numero di eliminazioni inaspettatamente elevato. Un utente successivo ha chiesto come ignorare tale soglia dopo aver rimosso deliberatamente migliaia di file. La discussione non ha risolto questo problema operativo.
Chiunque valuti il progetto deve verificare i percorsi dei rami, i percorsi di parità, i timer, le soglie di eliminazione e la posizione dei dati delle applicazioni prima di abilitare i processi automatici. Una verifica dei binari riuscita o un mount mergerfs funzionante non dimostrano che il ripristino della parità sia stato testato per un dataset di produzione.
Limiti del supporto
Si tratta di un'integrazione avanzata realizzata dalla community, non di una funzionalità di storage di ZimaOS supportata da IceWhale. Docker, una macchina virtuale Linux completa, i binari statici e sysext hanno privilegi e caratteristiche di persistenza differenti. Il risultato più significativo della discussione è il metodo con estensione testato, ma dovrebbe comunque essere valutato su uno storage temporaneo prima di introdurre dati reali.
FAQ
mergerfs è già incluso in ZimaOS?
Un partecipante ha verificato la presenza di un binario mergerfs sul proprio ZimaCube. In seguito, la discussione ha identificato quella copia di base come una versione precedente, quindi la sua presenza non garantisce la compatibilità con una configurazione moderna.
Il ripristino SnapRAID è stato testato completamente?
No. Il test controllato ha verificato l'installazione e un pool mergerfs temporaneo, ma si è esplicitamente fermato prima di un test completo di parità e ripristino SnapRAID.
Perché attendere il fallimento di un servizio non è stato sufficiente?
Una delle gare poteva produrre un pool vuoto con un codice di uscita positivo. Poiché non si trattava di un errore, una regola basata soltanto su restart-on-failure poteva non rilevarlo.
