Het sterkste argument in deze thread over functieverzoeken voor ZimaOS in 2025 was niet simpelweg “voeg nog een bestandssysteem toe”. Gebruikers wilden een opslagmodel vergelijkbaar met Unraid: schijven van verschillende groottes afzonderlijk geformatteerd houden, ze als één logische pool aanbieden en pariteitsbescherming toevoegen zonder de volledige verzameling om te zetten in een conventionele gestreepte RAID-array.
Zima-Giorgio vroeg waarom de aankomende JBOD-optie in ZimaOS 1.4.2 niet zou volstaan en verzocht om concrete praktijkgerichte workflows. De reacties maken het onderscheid duidelijk: JBOD kan capaciteit combineren, terwijl MergerFS plus SnapRAID aantrekkelijk is omdat het pooling scheidt van geplande pariteit en gebruikers in staat stelt een thuiscollectie met ongelijke schijven gedurende vele jaren uit te breiden.
Waarom thuis-NAS-gebruikers om MergerFS en SnapRAID vroegen
Verschillende deelnemers beschreven opslag die stapsgewijs groeit. Eén gebruiker had schijven van 3 TB, 6 TB en 12 TB. Een andere beschreef een keten waarbij een schijf van 8 TB een schijf van 6 TB in de hoofd-NAS vervangt, de vrijgekomen schijf van 6 TB naar een archiefsysteem gaat en een oudere archiefschijf opnieuw naar een homeserver in een homelab verhuist.
Traditionele RAID kan voor dat patroon onhandig zijn, omdat de bruikbare capaciteit en uitbreidingsregels vaak uitgaan van schijven met dezelfde grootte of van een zorgvuldige planning. De gebruikers wilden de waarde van bestaande schijven behouden in plaats van de volledige array opnieuw op te bouwen telkens wanneer er een grotere schijf wordt aangeschaft.
MergerFS en SnapRAID lossen verschillende problemen op
MergerFS is een unionbestandssysteem. Het kan meerdere onafhankelijke bestandssystemen onder één logisch koppelpunt tonen, terwijl de bestanden op de afzonderlijke schijven blijven staan.
SnapRAID is pariteitssoftware. Het berekent pariteitsinformatie op basis van bestanden op de gegevensschijven en kan integriteitscontroles uitvoeren. Pariteitssynchronisatie wordt normaal gesproken gepland uitgevoerd in plaats van continu weggeschreven te worden, zoals bij traditionele RAID.
Die scheiding is de reden waarom de combinatie populair is voor relatief statische mediacollecties: MergerFS levert de naamruimte van de pool, terwijl SnapRAID herstel mogelijk maakt na het uitvallen van geselecteerde schijven.
Waarom ZimaOS-JBOD niet hetzelfde ontwerp is
De huidige ZimaOS-documentatie beschrijft JBOD als het samenvoegen van meerdere schijven tot één doorlopend volume. Het is een capaciteitsoptie en niet hetzelfde pariteitsmodel als waar gebruikers om vroegen.
Voor de huidige ingebouwde opties kun je de RAID- en JBOD-opties in ZimaOS vergelijken. JBOD is nuttig wanneer het doel eenvoudig samengevoegde capaciteit is, maar het wordt niet automatisch SnapRAID alleen omdat de schijven verschillende groottes hebben.
De auteur van MergerFS nam deel aan de discussie
Trapexit, de ontwikkelaar van MergerFS, legde uit dat CasaOS van oudsher MergerFS gebruikte voor de opslagfunctie “samenvoegen”. Hij had eerder uitgebreidere integratie met IceWhale besproken, maar zei dat die gesprekken destijds niet hadden geleid tot een bredere integratie in ZimaOS.
Hij beschreef ook een geschikte werklast voor MergerFS: bestanden die één keer worden geschreven, vaak worden gelezen en zelden worden gewijzigd, waarbij een logische pool van onafhankelijke bestandssystemen belangrijker is dan hoge prestaties bij willekeurige schrijfbewerkingen.
Later in de thread verscheen een CasaOS-scherm voor samenvoegen
Deze schermafbeelding is bewijs van CasaOS en geen bewijs voor een actuele, ondersteunde ZimaOS-beheerpagina voor MergerFS.
Waarom gebruikers SnapRAID anders vinden dan realtimepariteit
De thread richtte zich herhaaldelijk op media-archieven waarin bestanden niet voortdurend veranderen. Met geplande pariteit kunnen ongebruikte schijven vaker in slaapstand gaan en hoeft niet elke schijf aan elke leesbewerking deel te nemen. Gebruikers waardeerden ook de integriteitscontroles van SnapRAID voor het detecteren van stille gegevenscorruptie.
De keerzijde is dat wijzigingen die na de laatste pariteitssynchronisatie zijn aangebracht, niet door die pariteitssnapshot worden beschermd. SnapRAID is daarom geen directe vervanging voor elke RAID-werklast.
Waar IceWhale zich daadwerkelijk toe heeft verbonden
De officiële reacties waren voorzichtig. Zima-Giorgio vroeg gebruikers eerst uit te leggen waarom MergerFS en SnapRAID onvervangbaar waren in vergelijking met JBOD. In november 2025 zei hij dat het team de feedback had ontvangen en het verzoek opnieuw zou overwegen.
Dat is niet hetzelfde als een producttoezegging, datum op de roadmap of releaseaankondiging.
Huidige status
De huidige documentatie over ZimaOS-opslag blijft gericht op afzonderlijke schijven, JBOD, RAID en ingebouwde opties rond ZFS. Er is momenteel geen officiële configuratiepagina voor SnapRAID in de opslaginterface van ZimaOS.
Later onderzoek door de community in 2026 vond een MergerFS-binair bestand op sommige ZimaOS-systemen en een communityproject voor systemd-sysext dat MergerFS plus SnapRAID verpakt. Dat zijn betekenisvolle ontwikkelingen, maar ze zijn niet hetzelfde als officiële SnapRAID-ondersteuning van de eerste partij met een ondersteunde ZimaOS-interface en levenscyclus.
Kies het opslagmodel op basis van de werklast
- Schijven van dezelfde grootte en continue redundantie: gebruik de ZimaOS-RAID-optie die past bij de gewenste fouttolerantie.
- Eenvoudige capaciteitsaggregatie zonder behoefte aan pariteit: JBOD kan volstaan.
- Media van verschillende groottes die grotendeels statisch zijn, met geplande pariteit: MergerFS plus SnapRAID is de workflow waar gebruikers in deze thread om vroegen.
- Kritieke gegevens die regelmatig veranderen: houd ongeacht de arraytechnologie afzonderlijke back-ups bij.
Pariteit is geen back-up
Het verzoek gaat over het overleven van een schijfstoring, niet over het herstellen van per ongeluk verwijderde gegevens, ransomware of de vernietiging van de volledige server. Voor een ontwerp met MergerFS/SnapRAID is nog steeds een afzonderlijk back-upplan nodig voor onvervangbare gegevens.
Veelgestelde vragen over MergerFS en SnapRAID
Heeft IceWhale officiële SnapRAID-ondersteuning aangekondigd?
Nee. Het team vroeg om praktijkvoorbeelden en zei later dat het de feedback opnieuw zou overwegen.
Is ZimaOS-JBOD gelijkwaardig aan MergerFS plus SnapRAID?
Nee. JBOD is capaciteitsaggregatie; het gevraagde ontwerp combineert een unionbestandssysteem met pariteitssynchronisatie.
Heeft ZimaOS communityprojecten rond MergerFS?
Ja, maar binaire bestanden en sysext-modules van de community mogen niet worden omschreven als een officiële beheerfunctie voor SnapRAID.
