Det korta svaret ändrades när communityn testade ZimaOS
De första svaren behandlade ZimaOS som ett minimalt system i appliance-stil utan en traditionell pakethanterare. De avrådde från att anta att apt install eller permanenta ändringar i basoperativsystemet skulle vara tillgängliga. Docker och en virtuell Debian- eller Ubuntu-maskin föreslogs som renare isoleringsgränser.
Senare praktiska kontroller gav en viktig korrigering: en deltagare hittade /usr/bin/mergerfs och mergerfs-fusermount redan installerade på en ZimaCube, medan ingen SnapRAID-binär hittades. En annan deltagare identifierade den medföljande mergerfs-versionen som äldre vid felsökning av startkapplöpningen. Slutsatsen var inte att ”inbyggd installation är omöjlig”, utan att ”manuella ändringar av värdsystemet saknar stöd och är versionskänsliga”.
Manuella binärer fungerade men medförde uppdateringsrisk
En användare byggde körbara filer i WSL2, kopierade dem till ZimaOS och rapporterade en fungerande lösning med två datadiskar och en paritetsdisk. Underhållaren för mergerfs påpekade att statiska byggen kan förenkla manuell distribution, men att containerbeteendet beror på om körmiljön har tillräckliga root-behörigheter för att exponera FUSE-monteringen som krävs.
Communityns svar varnade upprepade gånger för att kopiering av binärer till ett system i stil med ett oföränderligt system skapar underhållsarbete. OTA-uppdateringar kan ersätta eller krocka med manuella ändringar, och AI-genererade Linux-instruktioner innehöll fel under användarens experiment.
Communityn byggde ett systemd-sysext-lager
En bidragsgivare publicerade sedan ett communityprojekt med systemd-sysext för ZimaOS. Syftet var att lägga till mergerfs och SnapRAID som ett separat tilläggslager i stället för att ändra det skrivskyddade bassystemet direkt.
Ett kontrollerat test på en ZimaCube Pro bekräftade att lagret laddades, exponerade mergerfs 2.42.0 och SnapRAID 14.5 och kunde montera en tillfällig mergerfs-pool. Testaren skapade en fil via den poolade sökvägen och verifierade att den visades på den underliggande grenen innan poolen avmonterades korrekt.
Testet omfattade inte ett fullständigt SnapRAID-test av paritet och återställning. Testaren inaktiverade också de förvalda timers och tjänsterna innan något konfigurerades, så att de inte av misstag kunde påverka riktiga diskar.
Två startkapplöpningar hittades och korrigerades
Efter en omstart upptäckte en användare att poolen ibland misslyckades, medan en manuell start senare lyckades. Författaren till tillägget identifierade två separata kapplöpningar. För det första såg den ursprungliga kontrollen den gamla mergerfs-binär som tillhandahölls av basoperativsystemet och startade poolen innan tilläggets nyare binär hade lagts till. Den reviderade kontrollen sökte efter SnapRAID, som endast tillhandahölls av tillägget.
För det andra kunde mergerfs returnera ett lyckat resultat innan de fysiska gren-diskarna hade monterats, vilket skapade en tom pool som dolde lagringen när den anlände senare. En enkel loop med Restart=on-failure kunde inte fånga detta lyckade men tomma tillstånd. Projektet lade till uttryckliga kontroller som väntar på att varje grenmontering ska vara klar och vägrar bygga poolen över en saknad gren.
Författaren rapporterade verifiering efter kall omstart på ZimaOS 1.6.1 efter dessa ändringar. En användare med ett TerraMaster-kabinett med fyra diskar rapporterade också att poolen till slut visades efter att det tagit närmare en minut att montera diskarna.
SnapRAID-säkerhet kräver fortfarande operatörens granskning
Tillägget innehöll en raderingströskel som skulle stoppa synkroniseringen efter ett oväntat stort antal raderingar. En senare användare frågade hur tröskeln kunde åsidosättas efter att avsiktligt ha tagit bort tusentals filer. Tråden gav inget slutligt svar på den operativa frågan.
Alla som utvärderar projektet måste granska grensökvägar, paritetssökvägar, timers, raderingströsklar och platsen för programdata innan automatiserade jobb aktiveras. En lyckad binärkontroll eller mergerfs-montering är inte ett bevis på att paritetsåterställning har testats för en produktionsdatauppsättning.
Supportgräns
Detta är en avancerad community-byggd integration, inte en lagringsfunktion i ZimaOS som stöds av IceWhale. Docker, en fullständig virtuell Linux-maskin, statiska binärer och sysext har olika egenskaper vad gäller behörigheter och beständighet. Trådens starkaste resultat är den testade tilläggsmetoden, men den bör ändå utvärderas på tillfällig lagring innan några aktiva data introduceras.
Vanliga frågor
Ingår mergerfs redan i ZimaOS?
En deltagare verifierade en mergerfs-binär på sin ZimaCube. Tråden identifierade senare den baskopian som en äldre version, så dess närvaro garanterar inte kompatibilitet med en modern konfiguration.
Testades SnapRAID-återställning fullständigt?
Nej. Det kontrollerade testet verifierade installationen och en tillfällig mergerfs-pool, men avbröts uttryckligen innan ett fullständigt SnapRAID-test av paritet och återställning.
Varför räckte det inte att vänta på att en tjänst skulle misslyckas?
En kapplöpning kunde skapa en tom pool med en lyckad slutkod. Eftersom det inte räknades som ett fel kunde en regel med enbart omstart vid fel missa det.
