Det starkaste argumentet i denna tråd om funktionsönskemål för ZimaOS från 2025 var inte bara ”lägg till ännu ett filsystem”. Användarna ville ha en lagringsmodell liknande Unraid: behålla individuellt formaterade diskar i olika storlekar, presentera dem som en logisk pool och lägga till paritetsskydd utan att konvertera hela samlingen till en konventionell stripad RAID-array.
Zima-Giorgio svarade genom att fråga varför det kommande JBOD-alternativet i ZimaOS 1.4.2 inte skulle räcka och bad om konkreta arbetsflöden från verkligheten. Svaren tydliggör skillnaden: JBOD kan kombinera kapacitet, medan MergerFS plus SnapRAID är attraktivt eftersom det separerar poolning från schemalagd paritet och låter användare bygga ut en samling hemmamedia med olika diskar under många år.
Varför användare av hem-NAS efterfrågade MergerFS och SnapRAID
Flera deltagare beskrev lagring som växer stegvis. En användare hade diskar på 3 TB, 6 TB och 12 TB. En annan beskrev en kedja där en disk på 8 TB ersätter en disk på 6 TB i huvud-NAS:en, den undanträngda 6 TB-disken flyttas till ett arkivsystem och en äldre arkivdisk flyttas vidare till en homelab-server.
Traditionell RAID kan vara besvärlig för det mönstret eftersom användbar kapacitet och regler för utbyggnad ofta förutsätter matchade eller noggrant planerade diskar. Användarna ville bevara värdet i befintliga diskar i stället för att bygga om hela arrayen varje gång en större disk köps.
MergerFS och SnapRAID löser olika problem
MergerFS är ett fackfilsystem. Det kan få flera oberoende filsystem att visas under en enda logisk monteringspunkt, samtidigt som filerna fortfarande ligger på de enskilda medlemsdiskarna.
SnapRAID är paritetsprogramvara. Det beräknar paritetsinformation från filer på datadiskarna och kan tillhandahålla integritetskontroll. Paritetssynkronisering schemaläggs normalt i stället för att skrivas kontinuerligt som i traditionell RAID.
Det är denna uppdelning som gör kombinationen populär för relativt statiska mediesamlingar: MergerFS tillhandahåller poolens namnrymd, medan SnapRAID ger möjlighet att återställa efter fel på utvalda diskar.
Varför ZimaOS JBOD inte är samma design
Den aktuella dokumentationen för ZimaOS beskriver JBOD som att flera diskar sammanfogas till en sammanhängande volym. Det är ett kapacitetsalternativ, inte samma paritetsmodell som användarna efterfrågade.
För de aktuella inbyggda alternativen kan du jämföra RAID- och JBOD-alternativen som finns i ZimaOS. JBOD är användbart när målet är enkel sammanslagen kapacitet, men det blir inte SnapRAID bara för att medlemsdiskarna har olika storlekar.
MergerFS skapare deltog i diskussionen
Trapexit, utvecklaren av MergerFS, förklarade att CasaOS historiskt hade använt MergerFS för sin lagringsfunktion ”merge”. Han hade tidigare diskuterat djupare integration med IceWhale, men sade att dessa samtal inte hade utvecklats till en bredare ZimaOS-integration vid den tidpunkten.
Han beskrev också ett rimligt arbetsflöde för MergerFS: filer som skrivs en gång, läses många gånger och ändras sällan, där en logisk pool av oberoende filsystem är viktigare än hög prestanda vid slumpmässiga skrivningar.
En CasaOS-skärm för sammanfogning dök senare upp i tråden
Den här skärmbilden är ett belägg för CasaOS, inte ett bevis på en aktuell stödd MergerFS-hanteringssida i ZimaOS.
Varför användare anser att SnapRAID skiljer sig från paritet i realtid
Tråden fokuserade upprepade gånger på mediearkiv där filer inte ändras hela tiden. Schemalagd paritet gör att oanvända diskar kan försättas i viloläge oftare och undviker kravet att varje disk ska delta i varje läsning. Användarna uppskattade också SnapRAID:s integritetskontroller för att upptäcka tyst datakorruption.
Nackdelen är att ändringar som görs efter den senaste paritetssynkroniseringen inte skyddas av den paritetsögonblicksbilden. SnapRAID är därför inte en direkt ersättning för alla RAID-arbetsbelastningar.
Vad IceWhale faktiskt åtog sig
De officiella svaren var försiktiga. Zima-Giorgio bad först användarna förklara varför MergerFS och SnapRAID var oumbärliga jämfört med JBOD. I november 2025 sade han att teamet hade tagit emot återkopplingen och skulle ompröva önskemålet.
Det är inte samma sak som ett produktåtagande, ett datum i färdplanen eller ett lanseringsmeddelande.
Aktuell status
Den aktuella dokumentationen om lagring i ZimaOS är fortfarande centrerad kring enskilda diskar, JBOD, RAID och inbyggda ZFS-relaterade alternativ. Det finns ingen aktuell officiell SnapRAID-konfigurationssida i ZimaOS Storage UI.
Senare undersökningar i communityn under 2026 hittade en MergerFS-binär på vissa ZimaOS-system samt ett communityprojekt för systemd-sysext som paketerar MergerFS tillsammans med SnapRAID. Det är betydelsefull utveckling, men inte samma sak som förstapartssupport för SnapRAID med ett stödd ZimaOS-gränssnitt och en stödd livscykel.
Välj lagringsmodell utifrån arbetsbelastning
- Matchade diskar och kontinuerlig redundans: använd det ZimaOS-RAID-alternativ som passar den feltolerans du behöver.
- Enkel kapacitetsaggregering utan krav på paritet: JBOD kan räcka.
- Diskar i olika storlekar, huvudsakligen statiska medier och schemalagd paritet: MergerFS plus SnapRAID är det arbetsflöde som användarna i denna tråd efterfrågade.
- Kritiska data som ändras: behåll separata säkerhetskopior oavsett arrayteknik.
Paritet är inte en säkerhetskopia
Önskemålet handlar om att överleva ett diskfel, inte om oavsiktlig radering, utpressningstrojaner eller att hela servern förstörs. En MergerFS/SnapRAID-design behöver fortfarande en separat säkerhetskopieringsplan för oersättliga data.
Vanliga frågor om MergerFS och SnapRAID
Har IceWhale meddelat officiellt stöd för SnapRAID?
Nej. Teamet bad om användningsfall och sade senare att det skulle ompröva återkopplingen.
Är ZimaOS JBOD likvärdigt med MergerFS plus SnapRAID?
Nej. JBOD aggregerar kapacitet, medan den efterfrågade designen kombinerar ett fackfilsystem med paritetssynkronisering.
Finns det MergerFS-relaterat communityarbete för ZimaOS?
Ja, men communitybinärer och sysext-moduler bör inte beskrivas som en officiell SnapRAID-hanteringsfunktion.
