En hälsning från Zima
Tack, Ted, för att du dokumenterar ZimaCube 2 som ett system som växer lager för lager i stället för som en färdig lösning. Ditt Pioneer-bygge dokumenterar de lyckade uppgraderingarna, lagringsbenchmarkerna, Immich-migreringen och de delar som gjorde motstånd — däribland en Thunderbolt-väg som till slut blev en OCuLink-lösning. Genom att publicera mätningar, kringlösningar, misstag och förändrade hårdvarubeslut allt eftersom bygget utvecklas ger du communityn något mer användbart än ett slutligt specifikationsblad: en dokumentation av hur ett verkligt ZimaOS-hemlabb utvecklas.
— Zima
Möt ted-knight
Ted-knight dokumenterar ett av de mer metodiska ZimaCube 2-byggena i Pioneer Program. Hans ZimaCube 2 Build är inte organiserat kring en enda slutlig konfiguration. I stället är projektet indelat i faser, där varje lager testas innan nästa läggs till.
Målet med bygget är enkelt: att skapa en NAS som kan anförtros viktig data redan i dag, samtidigt som det finns tillräckligt med utrymme för självhostning, medier, lokal AI och andra arbetsbelastningar längre fram. Det har lett Ted genom lagringsarkitektur, ZFS, btrfs, uppgraderingar av RAM och NVMe, OCuLink-expansion, benchmarking, ZimaOS-integration, Immich-migrering och en allt mer detaljerad plan för vad maskinen kan bli härnäst.
Han började med ZimaCube 2 Standard: ett system med Intel Core i3-1215U, 8 GB DDR5 och en NVMe-systemenhet på 256 GB. Den ursprungliga konfigurationen förblev inte ursprunglig särskilt länge.
Bygga lagringsgrunden innan fler tjänster läggs till
Teds första prioritet var inte att fylla servern med applikationer. Det var att bestämma var olika typer av data skulle lagras.
Det resulterande systemet använder flera lagringsnivåer med avsiktligt olika uppgifter. ZimaOS ligger kvar på sin egen Kingston NVMe-enhet på 256 GB. En Crucial P510 NVMe-enhet på 2 TB blev Arctic-Storage, en btrfs-nivå för AppData, Docker-avbildningar, databaser och andra aktiva arbetsbelastningar. Fyra NVMe-enheter på 2 TB bildar glacier, en ZFS RAIDZ1-pool med ungefär 5,5 TB användbart utrymme. Senare blev fyra Seagate IronWolf-enheter på 4 TB en btrfs RAID5-pool på 12 TB för stora mediebibliotek och mindre frekvent använda data.
Arkitekturen handlar mindre om att få alla enheter att fungera likadant och mer om att anpassa lagringen efter arbetsbelastningen. Databaser med mycket slumpmässig I/O hör hemma på den snabba P510-enheten. Större sekventiella arbetsbelastningar och data som drar nytta av ZFS-kontrollsummor och redundans kan ligga på glacier. Massmedia kan flyttas till IronWolf-nivån med högre kapacitet.
När Thunderbolt 4 inte fungerade ändrades arkitekturen
En av de mest användbara delarna av teds projekt är att de misslyckade experimenten finns kvar i dokumentationen.
Den ursprungliga planen var att ansluta ett Aoostar TB4S-OC-hölje med fyra NVMe-enheter till ZimaCube 2 via Thunderbolt 4. Ted testade olika 40 Gbit/s-kablar, båda Thunderbolt-portarna, extern strömförsörjning och kärnans underliggande beteende, men höljet lyckades fortfarande inte upprätta en stabil PCIe-anslutning.
Utredningen pekade så småningom på samspelet mellan ZimaOS Thunderbolt-konfiguration och ASMedia ASM2462PDX-styrenheten i höljet. I stället för att fortsätta tvinga igenom den ursprungliga planen ändrade ted arkitekturen.
En PCIe x4-till-OCuLink-adapter installerades i kortplats 1. Aoostar-höljet gick från Thunderbolt till en direkt OCuLink-anslutning. Alla fyra NVMe-enheter identifierades vid den första uppstarten utan de tunnel- och auktoriseringsproblem som hade stoppat Thunderbolt-konfigurationen.
Förändringen påverkade även senare planer. Kortplats 1 är nu upptagen av lagring, medan de två Thunderbolt-portarna fortfarande är tillgängliga för framtida experiment, till exempel direktnätverk eller en annan eGPU-lösning. En misslyckad anslutning blev inte bara en fotnot i felsökningen; den förändrade hela maskinens färdplan.
Lagringstestning i stället för att anta vilken nivå som var snabbast
När lagringen väl fanns på plats mätte ted den.
Hans arbete i fas 1.5 använder fio för att jämföra glacier ZFS RAIDZ1-poolen med Arctic-Storage, i stället för att behandla ”NVMe” som en enda prestandakategori. Det kalla riktmärket visade att glacier nådde 1 726 MB/s i sekventiell skrivning och 2 591 MB/s i sekventiell läsning, medan Arctic-lagret med en enda enhet var betydligt starkare vid slumpmässig I/O och nådde 205 588 IOPS vid slumpmässig 4K-läsning på sin ursprungliga plats.
Det mer intressanta resultatet visade sig när ZFS ARC kom in i bilden. Upprepade läsningar från glacier kunde hämtas från RAM i stället för att gå tillbaka till NVMe-enheterna. Med den tidigare minneskonfigurationen på 16 GB nådde varma slumpmässiga läsningar ungefär 83 929 IOPS, jämfört med 14 781 IOPS i det kalla resultatet.
Det resultatet påverkade senare ett annat hårdvarubeslut. Ted uppgraderade maskinen till 32 GB med två 16 GB DDR5-moduler och gick från enkelkanals- till tvåkanalsminne. Efter uppgraderingen ökade de varma slumpmässiga ARC-läsningarna igen till 126 816 IOPS – en uppmätt förbättring på 51 procent jämfört med det tidigare resultatet.
Riktmärkena ifrågasatte också den ursprungliga placeringen av Crucial P510. I Standard-modellens sjunde fack begränsades den sekventiella genomströmningen av bryggan. Ted flyttade enheten till det inbyggda M.2-facket och uppmätte en ökning av den sekventiella läshastigheten från 874 MB/s till 1 677 MB/s, medan prestandan vid slumpmässig 4K-läsning ökade från 205 588 till 403 078 IOPS.
Lärdomen var inte bara att en plats var snabbare. Mätningarna förändrade var arbetsbelastningar borde placeras och vilka uppgraderingar som faktiskt var värda att genomföra.
Så fungerar ZFS bredvid ZimaOS
Bygget visar också en intressant gräns mellan det som ZimaOS hanterar inbyggt och det som en erfaren användare kan lägga till under systemet.
Ted använder medvetet btrfs för Arctic-Storage och IronWolf-poolen, eftersom de volymerna integreras naturligt med ZimaOS. glacier-poolen är annorlunda. Den skapades som ZFS RAIDZ1 från kommandoraden, vilket gav ted ZFS-datamängder, kontrollsummor, ARC-cache, ögonblicksbilder och en lagringsmodell som passade bättre för vissa av hans planerade arbetsbelastningar.
Den flexibiliteten har dock en nackdel: ZFS-pooler som skapas från kommandoraden visas inte som inbyggda ZimaOS-lagringsvolymer i gränssnittet.
Teds lösning är enkel och praktisk. Han exponerar de individuella ZFS-datamängderna via symboliska länkar under /DATA, blev det möjligt att låta sökvägar som glacier-dokument, media, säkerhetskopior och VM-lagring visas i ZimaOS Filer-appen, medan den underliggande poolen fortfarande hanteras via ZFS.
Han hittade ett annat synlighetsproblem med minnet. ZimaOS kan rapportera en stor del av RAM-minnet som ”använt” när ZFS ARC fyller annars ledigt minne. När han tittade på btop och ARC-statistiken berättar en mer användbar historia: cachen använder minne eftersom det finns tillgängligt, och ZFS kan frigöra det när program behöver mer.
Det här är den typ av återkoppling som är viktig i ett Pioneer-bygge. Ted visar inte bara vad som fungerar i ZimaOS; han dokumenterar också var en avancerad lagringskonfiguration når gränsen för det nuvarande gränssnittet och vad han gör när han kommer dit.
Flytta ett befintligt Immich-bibliotek utan att förlora historiken
Lagringsarkitekturen blir mycket mer betydelsefull när oersättlig data börjar flyttas till den.
För ted var det testet Immich. Han hade redan en Immich-instans igång på en äldre egenbyggd ZimaOS-server och ville flytta den till ZimaCube 2 utan att börja om från början.
Migreringen omfattade 14 505 foton och 925 videor — totalt 134 GiB. Men de viktiga uppgifterna var inte begränsade till bildfilerna. Album, personer, ansiktsigenkänning, minnen, delade länkar och andra metadata lagrades i PostgreSQL.
Med ZimaOS Filer-appen över det lokala nätverket kopierade ted båda /DATA/Gallery/immich och hela /DATA/AppData/immich katalogen, inklusive pgdata. Immich-instansen i källan stoppades innan kopieringen, så att PostgreSQL-data förblev konsekvent.
Efter migreringen var kontot, albumen, ansiktsinformationen, minnena och biblioteket intakta, utan någon rapporterad dataförlust. Ted verifierade sedan PostgreSQL-databasen direkt i stället för att anta att en lyckad inloggning betydde att allt hade bevarats.
Om du planerar samma typ av flytt går vår Immich-migreringsguide för ZimaCube 2 igenom samma viktiga skillnad: det räcker inte att bara flytta mediebiblioteket — databasen måste flyttas med.
Från en migrering på 134 GiB till 725 GiB självhostade foton och videor
Immich-fasen tog inte slut när migreringen från den gamla servern hade slutförts.
Det som började som en flytt av ett befintligt ZimaOS-bibliotek blev en betydligt större förändring, bort från att använda iCloud som den primära lagringsplatsen för teds foton och videor. Hans iPhone började överföra det ursprungliga iCloud-biblioteket till Immich, som kördes på ZimaCube 2.
I slutet av den fasen innehöll servern 63 665 objekt på totalt 725 GiB: 55 604 foton och 8 061 videor. Själva iCloud-överföringen stod för cirka 655 GB, där 4K-video utgjorde merparten av lagringsutrymmet.
Målet var inte att låtsas att alla Apples molntjänster kunde ersättas. Ted identifierade fortfarande enhets säkerhetskopior, meddelanden och andra iOS-specifika data som det är rimligt att behålla i en mindre iCloud-plan. Förändringen var mer fokuserad: flytta det stora foto- och videobiblioteket till lagring som han själv kontrollerar, samtidigt som molntjänsterna som fortfarande fyller en användbar funktion behålls.
Det beslutet skapade också ett nytt ansvar. Ett självhostat fotobibliotek blir bara säkrare än en molnkopia när det säkerhetskopieras ordentligt. Teds migreringsanteckningar omfattar därför även en andra kopia på TrueNAS, vilket lägger grunden för den bredare 3-2-1-säkerhetskopieringsfas som fortfarande finns på färdplanen.
Att bygga kring det som ZimaOS gör enkelt – och mäta resten
Ted valde ZimaOS medvetet. Efter flera år med Synology och som långvarig CasaOS-användare ville han ha den renare, Docker-fokuserade applikationsmodellen, samtidigt som han behöll åtkomsten till det underliggande systemet när bygget krävde något mer avancerat.
Flera delar av projektet drar nytta av den balansen. Det inbyggda verktyget för migrering av AppData flyttade Docker-applikationernas data från systemenheten till Arctic-Storage utan att alla appar behövde byggas om. Filer-appen tillhandahöll det LAN-arbetsflöde som användes för Immich-migreringen. Inbyggda verktyg som fio, zpool, zfs, nvme, och iostat gjorde det möjligt att mäta och hantera lagringsarkitekturen under det grafiska lagret.
Andra delar visar var upplevelsen fortfarande är mindre integrerad. ZFS-lagring som skapats via CLI kräver en lösning med symboliska länkar. ARC gör det lätt att misstolka den vanliga RAM-siffran. Thunderbolt-beteendet tvingade fram en omdesign av hårdvaran.
De observationerna gör projektet mer värdefullt än en uppvisning där varje experiment fungerar på första försöket. Ted dokumenterar gränsen mellan en enkel ZimaOS-upplevelse och det djupare homelab-arbete som börjar när någon bestämmer sig för att gå över den.
Vad som redan är byggt – och vad som fortfarande är en färdplan
Titeln på teds repository beskriver målet som en blygsam AI-driven NAS, men projektet byggs medvetet i faser.
Grunden är redan på plats. Lagring i nivåer körs redan. Glacier ZFS RAIDZ1-poolen är i drift. Arctic-Storage har flyttats till den inbyggda M.2-platsen. Minnet har uppgraderats till 32 GB i tvåkanalsläge. IronWolf RAID5-poolen finns. Lagringsbenchmarkar har slutförts. Migreringen till Immich och den bredare konsolideringen av iCloud-bilder är klara.
Medielagret växer fortfarande. IronWolf-poolen har skapats för stora mediemängder, medan Jellyfin och den bredare *arr-stacken fortfarande ingår i det pågående arbetet i fas 2.
AI-lagren ligger fortfarande framför oss. Teds färdplan placerar för närvarande CPU-tester med Ollama i fas 4a, följt av en RTX 4090 eGPU-väg i fas 4b och semantisk sökning över lokal lagring i fas 5.
Den skillnaden är viktig. ZimaCube 2 förbereds redan för lokal AI genom lagringsplacering, minneskapacitet, PCIe-beslut och planering av arbetsbelastningar, men projektet har ännu inte nått den punkt där GPU-inferens bör presenteras som ett färdigt resultat.
För läsare som redan nu utforskar den framtida inriktningen går vår guide till lokal AI på ZimaCube 2 igenom hur Ollama, minne, PCIe-expansion och senare GPU-uppgraderingar kan passa in i en liknande färdplan för ett homelab.
Ett bygge som förändras när bevisen förändras
Det mest konsekventa mönstret i teds projekt är inte ZFS, Immich eller någon särskild hårdvarudel. Det är villigheten att ändra ett beslut efter att ha mätt vad som faktiskt hände.
Thunderbolt-kabinettet fungerade inte, så lagringsvägen flyttades till OCuLink.
P510 kunde inte utnyttja sin potential i den 7:e platsen, så den flyttades till den inbyggda M.2-platsen.
ZFS ARC presterade bättre än väntat, så minnet blev en prestandauppgradering snarare än bara ytterligare kapacitet.
En Immich-migrering på 134 GiB genomfördes utan att databasen gick förlorad, så experimentet utökades med att flytta ytterligare hundratals gigabyte från iCloud.
Varje fas lämnar efter sig mätvärden, kommandon, misstag och uppdaterade antaganden inför nästa fas. Det gör arkivet användbart även för den som aldrig bygger exakt samma lagringskonfiguration.
Berättelsen skrivs fortfarande
Berättelsen om ted-knight och Zima skrivs fortfarande. ZimaCube 2 började som en Standard-modell med 8 GB och har redan blivit ett lagringssystem i flera nivåer med btrfs, ZFS RAIDZ1, OCuLink NVMe-expansion, 32 GB minne i dubbelkanal, ett IronWolf RAID5-arkiv och ett egenhostat Immich-bibliotek med hundratals gigabyte personliga medier.
Nästa faser är medvetet fortfarande öppna: Jellyfin och mediestacken, robustare säkerhetskopieringsflöden, lokal AI som körs enbart på CPU, en framtida GPU-väg, semantisk sökning och allt annat som mätningarna får ted att ompröva längs vägen.
Om du vill följa bygget när dessa faser går från färdplan till faktiska resultat kan du följa ted-knights pågående ZimaCube 2-bygge på GitHub.
