Een opmerking van Zima
Bedankt, Ted, voor het documenteren van de ZimaCube 2 als een systeem dat in lagen groeit in plaats van een afgewerkt apparaat te zijn. Je Pioneer-build legt de geslaagde upgrades, de opslagbenchmarks, de migratie naar Immich en de onderdelen die tegenwerkten vast — waaronder een Thunderbolt-pad dat uiteindelijk een OCuLink-oplossing werd. Door de metingen, workarounds, fouten en veranderende hardwarekeuzes tijdens de ontwikkeling van de build te publiceren, geef je de community iets dat nuttiger is dan een definitief specificatieblad: een verslag van hoe een echte ZimaOS-homelab zich ontwikkelt.
— Zima
Maak kennis met ted-knight
Ted-knight documenteert een van de meest methodische ZimaCube 2-builds binnen het Pioneer Program. Zijn ZimaCube 2 Build is niet georganiseerd rond één uiteindelijke configuratie. In plaats daarvan is het project opgedeeld in fasen, waarbij elke laag wordt getest voordat de volgende wordt toegevoegd.
Het doel van de build is eenvoudig: een NAS creëren die vandaag aan belangrijke data kan worden toevertrouwd en tegelijkertijd voldoende ruimte overlaat voor selfhosting, media, lokale AI en andere workloads in de toekomst. Dat heeft Ted geleid langs opslagarchitectuur, ZFS, btrfs, RAM- en NVMe-upgrades, OCuLink-uitbreiding, benchmarks, ZimaOS-integratie, de migratie naar Immich en een steeds gedetailleerdere routekaart voor wat de machine hierna kan worden.
Hij begon met de ZimaCube 2 Standard: een systeem met een Intel Core i3-1215U, 8 GB DDR5 en een NVMe-systeemschijf van 256 GB. De oorspronkelijke configuratie bleef niet lang ongewijzigd.
De opslagbasis bouwen voordat er meer services worden toegevoegd
Teds eerste prioriteit was niet om de server met applicaties te vullen. Het was bepalen waar verschillende soorten data moesten worden opgeslagen.
Het uiteindelijke systeem gebruikt meerdere opslaglagen met bewust verschillende functies. ZimaOS blijft op zijn eigen Kingston NVMe van 256 GB staan. Een Crucial P510 NVMe van 2 TB werd Arctic-Storage, een btrfs-laag voor AppData, Docker-images, databases en andere actieve workloads. Vier NVMe-schijven van 2 TB vormen glacier, een ZFS RAIDZ1-pool met ongeveer 5,5 TB bruikbare ruimte. Later werden vier Seagate IronWolf-schijven van 4 TB een btrfs RAID5-pool van 12 TB voor bulkmedia en minder vaak gebruikte data.
De architectuur draait er minder om elke schijf hetzelfde te laten werken en meer om opslag af te stemmen op de werklast. Databases met veel willekeurige I/O horen op de snelle P510. Grotere sequentiële werklasten en gegevens die baat hebben bij ZFS-controlesommen en redundantie kunnen op glacier staan. Bulkmedia kan naar de IronWolf-laag met hogere capaciteit.
Toen Thunderbolt 4 niet werkte, veranderde de architectuur
Een van de nuttigste aspecten van teds project is dat de mislukte experimenten in de documentatie zijn opgenomen.
Het oorspronkelijke plan was om een Aoostar TB4S-OC-behuizing voor vier NVMe-schijven via Thunderbolt 4 met de ZimaCube 2 te verbinden. Ted testte verschillende 40Gbps-kabels, beide Thunderbolt-poorten, externe voeding en het onderliggende kernelgedrag, maar de behuizing kon nog steeds geen stabiele PCIe-verbinding tot stand brengen.
Het onderzoek wees uiteindelijk op de wisselwerking tussen de Thunderbolt-configuratie van ZimaOS en de ASMedia ASM2462PDX-controller in de behuizing. In plaats van het oorspronkelijke plan te blijven forceren, wijzigde ted de architectuur.
Een PCIe x4-naar-OCuLink-adapter werd in Slot 1 geplaatst. De Aoostar-behuizing werd van Thunderbolt overgezet naar een directe OCuLink-verbinding. Alle vier de NVMe-schijven verschenen bij de eerste keer opstarten, zonder de tunneling- en autorisatieproblemen die de Thunderbolt-configuratie hadden geblokkeerd.
De wijziging had ook gevolgen voor latere plannen. Slot 1 wordt nu ingenomen door opslag, terwijl de twee Thunderbolt-poorten beschikbaar blijven voor toekomstige experimenten, zoals directe netwerkverbindingen of een andere eGPU-opstelling. Een mislukte verbinding werd niet simpelweg een voetnoot bij het oplossen van problemen; ze veranderde de routekaart van de hele machine.
Benchmarking van de opslag in plaats van aannemen welke laag sneller was
Toen de opslag eenmaal beschikbaar was, mat ted de prestaties ervan.
Voor zijn werk in fase 1.5 gebruikt hij fio om de ZFS RAIDZ1-pool van glacier te vergelijken met Arctic-Storage, in plaats van ‘NVMe’ als één prestatiecategorie te behandelen. De koude benchmark liet zien dat glacier 1.726 MB/s aan sequentiële schrijfsnelheid en 2.591 MB/s aan sequentiële leessnelheid behaalde, terwijl de Arctic-laag met één schijf veel sterker was bij willekeurige I/O, met 205.588 willekeurige 4K-lees-IOPS op de oorspronkelijke locatie.
Het interessantere resultaat verscheen toen ZFS ARC in beeld kwam. Herhaalde reads van glacier konden vanuit het RAM-geheugen worden bediend in plaats van opnieuw van de NVMe-schijven te worden gelezen. Met de eerdere geheugenconfiguratie van 16 GB bereikten warme willekeurige reads ongeveer 83.929 IOPS, tegenover het koude resultaat van 14.781 IOPS.
Die bevinding had later invloed op een andere hardwarebeslissing. Ted breidde de machine uit naar 32 GB met twee DDR5-modules van 16 GB, en stapte daarmee over van single-channel- naar dual-channel-geheugen. Na de upgrade stegen de willekeurige reads uit warm ARC opnieuw, naar 126.816 IOPS — een gemeten verbetering van 51 procent ten opzichte van het eerdere resultaat.
De benchmarks zetten ook de oorspronkelijke plaatsing van de Crucial P510 ter discussie. In de 7e bay van het Standard-model werd de sequentiële doorvoer beperkt door de bridge. Ted verplaatste de schijf naar het ingebouwde M.2-slot en mat een stijging van de sequentiële leessnelheid van 874 MB/s naar 1.677 MB/s, terwijl de prestaties bij willekeurig 4K-lezen stegen van 205.588 naar 403.078 IOPS.
De les was niet simpelweg dat één slot sneller was. De metingen veranderden waar workloads thuishoorden en welke upgrades daadwerkelijk de moeite waard waren.
ZFS naast ZimaOS laten werken
De build laat ook een interessante grens zien tussen wat ZimaOS native beheert en wat een ervaren gebruiker eronder kan toevoegen.
Ted gebruikt bewust btrfs voor Arctic-Storage en de IronWolf-pool, omdat die volumes vanzelf goed integreren met ZimaOS. De glacier-pool is anders. Die is vanaf de opdrachtregel aangemaakt als ZFS RAIDZ1, waardoor ted ZFS-datasets, checksums, ARC-caching en snapshots kreeg, plus een opslagmodel dat beter aansloot op enkele van zijn geplande workloads.
Aan die flexibiliteit zit wel een ruwe kant: ZFS-pools die vanaf de opdrachtregel zijn aangemaakt, verschijnen in de interface niet als native ZimaOS-opslagvolumes.
De workaround van Ted is eenvoudig en praktisch. Hij maakt de afzonderlijke ZFS-datasets beschikbaar via symbolische koppelingen onder /DATA, waardoor paden zoals documenten, media, back-ups en VM-opslag van glacier in de ZimaOS Bestanden-app kunnen verschijnen, terwijl de onderliggende pool door ZFS beheerd blijft.
Hij ontdekte nog een probleem met de zichtbaarheid van geheugen. ZimaOS kan een groot deel van het RAM-geheugen als ‘gebruikt’ rapporteren wanneer ZFS ARC anders inactief geheugen vult. Bij het bekijken van btop en ARC-statistieken vertellen een nuttiger verhaal: de cache gebruikt geheugen omdat het beschikbaar is, en ZFS kan het vrijgeven wanneer toepassingen meer nodig hebben.
Dit is het soort feedback dat ertoe doet bij een Pioneer-build. Ted laat niet alleen zien wat in ZimaOS werkt; hij documenteert ook waar een geavanceerde opslagconfiguratie de grenzen van de huidige gebruikersinterface bereikt en wat hij doet wanneer dat gebeurt.
Een bestaande Immich-bibliotheek verplaatsen zonder de geschiedenis te verliezen
De opslagarchitectuur wordt pas echt betekenisvol wanneer onvervangbare gegevens erop worden gezet.
Voor ted was die test Immich. Hij had al een Immich-instantie draaien op een oudere doe-het-zelf-ZimaOS-server en wilde die naar de ZimaCube 2 verplaatsen zonder opnieuw te beginnen.
Bij de migratie ging het om 14.505 foto's en 925 video's — in totaal 134 GiB. Maar de belangrijke gegevens waren niet beperkt tot de afbeeldingsbestanden. Albums, personen, gezichtsherkenning, herinneringen, gedeelde links en andere metadata stonden in PostgreSQL.
Met de Bestanden-app van ZimaOS via het LAN kopieerde ted beide /DATA/Gallery/immich en de volledige /DATA/AppData/immich map, inclusief pgdata. De oorspronkelijke Immich-instantie werd vóór het kopiëren gestopt, zodat de PostgreSQL-gegevens consistent bleven.
Na de migratie bleven het account, de albums, gezichtsgegevens, herinneringen en de bibliotheek intact, zonder gemeld gegevensverlies. Ted controleerde vervolgens de PostgreSQL-database rechtstreeks, in plaats van ervan uit te gaan dat een geslaagde login betekende dat alles behouden was gebleven.
Als je van plan bent een vergelijkbare overstap te maken, legt onze Immich-migratiehandleiding voor ZimaCube 2 dezelfde belangrijke nuance uit: alleen de mediabibliotheek verplaatsen is niet genoeg — de database moet mee worden verplaatst.
Van een migratie van 134 GiB naar 725 GiB aan zelfgehoste foto's en video's
De Immich-fase eindigde niet toen de migratie van de oude server was geslaagd.
Wat begon als het verplaatsen van een bestaande ZimaOS-bibliotheek, groeide uit tot een veel grotere overstap: iCloud niet langer gebruiken als de primaire opslagplaats voor teds foto's en video's. Zijn iPhone begon de oorspronkelijke iCloud-bibliotheek over te zetten naar Immich, dat op de ZimaCube 2 draaide.
Aan het einde van die fase bevatte de server 63.665 items met een totale omvang van 725 GiB: 55.604 foto's en 8.061 video's. De iCloud-overdracht zelf was goed voor ongeveer 655 GB, waarbij 4K-video het grootste deel van die opslag in beslag nam.
Het doel was niet te doen alsof elke Apple-cloudservice kon worden vervangen. Ted identificeerde nog steeds apparaatback-ups, berichten en andere iOS-specifieke gegevens die beter in een kleiner iCloud-abonnement kunnen blijven. De wijziging was gerichter: de grote foto- en videobibliotheek verplaatsen naar opslag die hij zelf beheert, terwijl de cloudservices die nog een nuttig doel dienen behouden blijven.
Die beslissing bracht ook een nieuwe verantwoordelijkheid met zich mee. Een zelfgehoste fotobibliotheek wordt pas veiliger dan een cloudkopie als er goede back-ups van worden gemaakt. Teds migratienotities gaan daarom verder met een tweede kopie op TrueNAS, als basis voor de bredere 3-2-1-back-upfase die nog op de roadmap staat.
Bouwen rond wat ZimaOS eenvoudig maakt — en de rest meten
Ted koos bewust voor ZimaOS. Na jarenlang Synology te hebben gebruikt en lange tijd CasaOS-gebruiker te zijn geweest, wilde hij het schonere, op Docker gerichte applicatiemodel behouden, terwijl hij nog steeds toegang hield tot het onderliggende systeem wanneer de build iets geavanceerders vereiste.
Verschillende onderdelen van het project maken gebruik van die balans. De ingebouwde AppData-migratietool verplaatste Docker-applicatiegegevens van de systeemschijf naar Arctic-Storage, zonder alle apps opnieuw op te bouwen. De Bestanden-app bood de LAN-workflow die voor de Immich-migratie werd gebruikt. Native tools, waaronder fio, zpool, zfs, nvme, en iostat maakte het mogelijk om de opslagarchitectuur onder de grafische laag te meten en te beheren.
Andere onderdelen laten zien waar de ervaring nog minder geïntegreerd is. ZFS-opslag die via de CLI is aangemaakt, vereist de symlink-workaround. ARC maakt het standaard RAM-aantal makkelijk verkeerd te interpreteren. Het gedrag van Thunderbolt maakte een hardwareherontwerp noodzakelijk.
Die observaties maken het project waardevoller dan een showcase waarin elk experiment meteen bij de eerste poging werkt. Ted documenteert de grens tussen een eenvoudige ZimaOS-ervaring en het diepere homelabwerk dat begint zodra iemand besluit die grens over te steken.
Wat al gebouwd is — en wat nog op de roadmap staat
De titel van teds repository beschrijft de bestemming als een bescheiden AI-aangestuurde NAS, maar het project wordt bewust in fases opgebouwd.
De basis is al realiteit. Getrapte opslag draait al. De glacier ZFS RAIDZ1-pool is operationeel. Arctic-Storage is verplaatst naar de ingebouwde M.2-slot. Het geheugen is uitgebreid naar 32 GB in dual-channelmodus. De IronWolf RAID5-pool bestaat. De opslagbenchmarks zijn afgerond. De Immich-migratie en de bredere consolidatie van iCloud-foto's zijn voltooid.
De medialaag groeit nog steeds. De IronWolf-pool is aangemaakt voor grote hoeveelheden media, terwijl de Jellyfin- en bredere *arr-stack nog steeds deel uitmaakt van het huidige fase 2-werk.
De AI-lagen liggen nog in de toekomst. Op teds roadmap staan momenteel CPU-only Ollama-tests in fase 4a, gevolgd door een RTX 4090 eGPU-traject in fase 4b en semantisch zoeken in lokale opslag in fase 5.
Dat onderscheid is belangrijk. De ZimaCube 2 wordt al voorbereid op lokale AI door de plaatsing van opslag, geheugencapaciteit, PCIe-keuzes en workloadplanning, maar het project heeft nog niet het punt bereikt waarop GPU-inferentie als een voltooid resultaat moet worden gepresenteerd.
Voor lezers die deze toekomstige richting nu al verkennen, bekijkt onze gids voor lokale AI op ZimaCube 2 hoe Ollama, geheugen, PCIe-uitbreiding en latere GPU-upgrades in een vergelijkbare homelab-roadmap passen.
Een build die verandert wanneer het bewijs verandert
Het meest consistente patroon in teds project is niet ZFS, Immich of een specifiek stuk hardware. Het is de bereidheid om een beslissing te wijzigen nadat is gemeten wat er daadwerkelijk is gebeurd.
De Thunderbolt-behuizing werkte niet, dus werd het opslagpad verplaatst naar OCuLink.
De P510 kon zijn potentieel in de 7e bay niet benutten en verhuisde daarom naar de ingebouwde M.2-sleuf.
ZFS ARC presteerde beter dan verwacht, waardoor geheugen een prestatie-upgrade werd in plaats van alleen extra capaciteit.
Een Immich-migratie van 134 GiB verliep zonder dat de database verloren ging, waarna het experiment werd uitgebreid met het verplaatsen van nog honderden gigabytes uit iCloud.
Elke fase laat metingen, opdrachten, fouten en bijgewerkte aannames voor de volgende fase achter. Daardoor is de repository ook nuttig voor iemand die niet exact dezelfde opslagconfiguratie bouwt.
Het verhaal wordt nog steeds geschreven
Het verhaal van ted-knight en Zima wordt nog steeds geschreven. De ZimaCube 2 begon als een Standard-model van 8 GB en is al uitgegroeid tot een opslagsysteem met meerdere lagen, met btrfs, ZFS RAIDZ1, OCuLink NVMe-uitbreiding, 32 GB dual-channelgeheugen, een IronWolf RAID5-archief en een zelfgehoste Immich-bibliotheek met honderden gigabytes aan persoonlijke media.
De volgende fasen liggen bewust nog open: Jellyfin en de medias stack, sterkere back-upworkflows, lokale AI die alleen de CPU gebruikt, een toekomstig GPU-traject, semantisch zoeken en alles wat ted onderweg op basis van de metingen opnieuw moet overwegen.
Als je de build wilt volgen terwijl die fasen van roadmap naar concrete resultaten gaan, volg dan teds voortdurende ZimaCube 2-build op GitHub.
