Het korte antwoord veranderde toen de community ZimaOS testte
In de eerste reacties werd ZimaOS beschouwd als een minimaal, appliance-achtig systeem zonder traditionele pakketbeheerder. Er werd afgeraden om ervan uit te gaan dat apt install of permanente wijzigingen aan het basissysteem beschikbaar zouden zijn. Docker en een virtuele Debian- of Ubuntu-machine werden voorgesteld als betere isolatiegrenzen.
Latere praktische controles brachten een belangrijke correctie aan: één deelnemer vond /usr/bin/mergerfs en mergerfs-fusermount al op een ZimaCube, terwijl er geen SnapRAID-binary werd gevonden. Een andere deelnemer stelde tijdens het debuggen van een opstartconflict vast dat de meegeleverde mergerfs een oudere versie was. Het resultaat was niet “native installatie is onmogelijk”, maar “handmatige wijzigingen aan de host worden niet ondersteund en zijn versieafhankelijk”.
Handmatige binaries werkten, maar brachten update-risico's met zich mee
Een gebruiker bouwde uitvoerbare bestanden in WSL2, kopieerde ze naar ZimaOS en meldde een werkende configuratie met twee gegevensschijven en één pariteitsschijf. De maintainer van mergerfs merkte op dat statische builds handmatige implementatie kunnen vereenvoudigen, maar dat het gedrag in containers afhangt van de vraag of de runtime voldoende rootrechten heeft om de FUSE-koppeling zoals vereist beschikbaar te maken.
Communityreacties waarschuwden herhaaldelijk dat het kopiëren van binaries naar een systeem in immutable stijl onderhoudswerk oplevert. OTA-updates kunnen handmatige wijzigingen vervangen of ermee conflicteren, en tijdens de experimenten van de gebruiker bleken AI-gegenereerde Linux-instructies fouten te bevatten.
De community bouwde een systemd-sysext-laag
Een bijdrager publiceerde vervolgens een community systemd-sysext-project voor ZimaOS. Het doel was om mergerfs en SnapRAID als een afzonderlijke uitbreidingslaag toe te voegen in plaats van het alleen-lezen basissysteem rechtstreeks te wijzigen.
Een gecontroleerde test op een ZimaCube Pro bevestigde dat de laag werd geladen, mergerfs 2.42.0 en SnapRAID 14.5 beschikbaar maakte en een tijdelijke mergerfs-pool kon koppelen. De tester maakte een bestand aan via het gepoolde pad en controleerde dat het vóór het netjes ontkoppelen op de onderliggende tak verscheen.
Die test omvatte geen volledige SnapRAID-test voor pariteit en herstel. De tester schakelde ook de standaardtimers en -services uit voordat er iets werd geconfigureerd, zodat ze niet per ongeluk echte schijven konden aanspreken.
Er werden twee opstartconflicten gevonden en opgelost
Na een herstart ontdekte een gebruiker dat de pool soms niet werd gekoppeld, terwijl een handmatige start later wel slaagde. De auteur van de extensie identificeerde twee afzonderlijke conflicten. Ten eerste zag de oorspronkelijke controle de oude mergerfs-binary die door het basissysteem werd geleverd en startte de pool voordat de nieuwere binary van de extensie was samengevoegd. De aangepaste controle controleerde op SnapRAID, dat alleen door de extensie werd geleverd.
Ten tweede kon mergerfs succes retourneren voordat de fysieke takschijven waren gekoppeld, waardoor een lege pool ontstond die de later beschikbare opslag verbergde. Een eenvoudige Restart=on-failure-lus kon die toestand, waarin alles succesvol maar leeg was, niet detecteren. Het project voegde expliciete controles toe die wachten totdat elke tak is gekoppeld en weigeren de pool op te bouwen wanneer een tak ontbreekt.
De auteur meldde na deze wijzigingen een controle met koude herstarten op ZimaOS 1.6.1. Een gebruiker met een TerraMaster-behuizing met vier schijven meldde ook dat de pool uiteindelijk verscheen nadat het bijna een minuut had geduurd voordat de schijven waren gekoppeld.
Veilig gebruik van SnapRAID vereist nog steeds controle door de beheerder
De extensie bevatte een verwijderingsdrempel die synchronisatie moest stoppen na een onverwacht groot aantal verwijderingen. Een latere gebruiker vroeg hoe die drempel kon worden overschreden nadat opzettelijk duizenden bestanden waren verwijderd. De thread gaf geen definitief antwoord op die operationele vraag.
Iedereen die het project beoordeelt, moet de takpaden, pariteitspaden, timers, verwijderingsdrempels en de locatie van applicatiegegevens controleren voordat geautomatiseerde taken worden ingeschakeld. Een geslaagde controle van binaries of een mergerfs-koppeling bewijst niet dat pariteitsherstel voor een productiedataset is getest.
Ondersteuningsgrens
Dit is een geavanceerde integratie die door de community is gebouwd, geen door IceWhale ondersteunde opslagfunctie van ZimaOS. Docker, een volledige Linux-VM, statische binaries en sysext hebben elk andere rechten en kenmerken voor persistentie. Het sterkste resultaat van de thread is de geteste uitbreidingsmethode, maar die moet nog steeds op tijdelijke opslag worden geëvalueerd voordat er livegegevens worden toegevoegd.
Veelgestelde vragen
Is mergerfs al opgenomen in ZimaOS?
Een deelnemer controleerde een mergerfs-binary op hun ZimaCube. Later stelde de thread vast dat die basisversie verouderd was. De aanwezigheid ervan garandeert dus geen compatibiliteit met een moderne configuratie.
Is SnapRAID-herstel volledig getest?
Nee. De gecontroleerde test bevestigde de installatie en een tijdelijke mergerfs-pool, maar stopte uitdrukkelijk vóór een volledige test van SnapRAID-pariteit en herstel.
Waarom was wachten op een mislukte service niet voldoende?
Een van de conflicten kon een lege pool veroorzaken met een succesvolle afsluitcode. Omdat dat niet als fout werd beschouwd, kon een regel voor opnieuw starten bij fouten dit alleen niet detecteren.
