SSD-leescache versus directe schijftoegang voor NAS-leesbewerkingen door meerdere gebruikers: wanneer verandert gedeeld hergebruik de winnaar?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

SSD Read Cache vs Direct Disk for Multi-User NAS Reads: When Does Shared Reuse Change the Winner? - Zima Store Online

SSD-leescache wordt waardevoller in een NAS voor meerdere gebruikers wanneer verschillende clients herhaaldelijk dezelfde veelgebruikte blokken opvragen nadat die blokken niet langer in het RAM passen. Rechtstreekse schijftoegang blijft de betere basis wanneer gebruikers voornamelijk verschillende gegevens lezen, de werklast sequentieel is of de HDD-pool verzoeken al sneller verwerkt dan het clientnetwerk ze kan afnemen.

De nieuwe beslisvariabele is gedeeld hergebruik. Tien gebruikers maken cache niet automatisch nuttig: tien mensen die tien niet-gerelateerde archieven lezen, kunnen vrijwel geen herbruikbare werklast creëren, terwijl drie editors die herhaaldelijk dezelfde projectassets openen, één gecachete kopie kunnen omzetten in veel vermeden schijflezingen. Meet overlap, niet het aantal gebruikers.

Gedeeld hergebruik moet de RAM-cache overleven voordat SSD-cache voordeel oplevert

Herhaalde leesbewerkingen komen normaal eerst in aanraking met RAM en pas daarna met een SSD-cache. Op ZFS is ARC de primaire leescache en L2ARC de secundaire SSD/NVMe-laag. Wanneer een tweede gebruiker hetzelfde bestand opent, kan dat “SSD-snel” lijken, terwijl de gegevens nooit het geheugen verlaten. Een warme test met meerdere gebruikers moet daarom vaststellen welke laag het verzoek heeft verwerkt.

Klara Systems legt uit dat L2ARC blokken opslaat die anders uit ARC zouden worden verwijderd en het nuttigst is wanneer de actieve werklast groter is dan het RAM, maar nog klein genoeg om binnen het RAM plus L2ARC te passen. De analyse uit 2026 over de omvang van de werklast voor L2ARC geeft de juiste eerste drempel: SSD-cache is pas relevant nadat geheugenmissers echte backend-lezingen veroorzaken.

Als ARC of de paginacache van het besturingssysteem al een hoge hitratio levert voor de gedeelde gegevens, kan het toevoegen van SSD-cache alleen kopieën naar een tragere laag verplaatsen en tegelijk geheugen verbruiken voor cachemetadata. Rechtstreekse schijftoegang is in die situatie niet eens de echte concurrent; RAM heeft al gewonnen.

Meerdere gebruikers helpen alleen wanneer hun veelgebruikte gegevens overlappen

Toegang door meerdere gebruikers verandert de cache-economie wanneer verzoeken samenkomen rond gemeenschappelijke gegevens: gedeelde projectmappen, softwarepakketten, VM-sjablonen, miniaturen, indexen, referentiemedia of vaak bekeken teammappen. Eén SSD-kopie kan herhaalde missers van meerdere clients afhandelen, waardoor mechanische zoekbewegingen afnemen en HDD-wachtrijen tijdens drukke perioden korter worden.

De bredere richtlijnen van Klara voor prestatieoptimalisatie beschrijven ARC als een balans tussen recentheid en frequentie en merken op dat vaak hergebruikte blokken zich anders gedragen dan eenmalige scans. Het frequentiebewuste cachegedrag is hier het belangrijke mechanisme: gedeeld hergebruik verhoogt de kans dat een door de ene gebruiker gepromoveerd blok nog steeds nuttig is voor een andere gebruiker.

Het aantal gebruikers zonder overlap kan het tegenovergestelde veroorzaken. Als elk gezinslid of werkstation een afzonderlijke dataset leest, groeit de gecombineerde werklast sneller en kunnen zowel de RAM- als de SSD-cache gaan thrashen. Meer gebruikers verlagen dan de hitratio in plaats van die te verbeteren. De vraag is dus “hoeveel gemeenschappelijke veelgebruikte gegevens zijn er?” en niet “hoeveel clients zijn verbonden?”

Rechtstreekse schijftoegang wint wanneer sequentiële doorvoer of het netwerk de bovengrens bepaalt

Grote mediaweergave, verificatie van back-ups en eenmalige scans van archieven verlopen vaak sequentieel en raken elk blok mogelijk maar één keer. Een gezonde HDD-pool met meerdere schijven kan dit verkeer efficiënt streamen, terwijl de cache weinig toekomstig hergebruik ziet. Als 2.5GbE of 1GbE al verzadigd is, kan het serveren van dezelfde leesbewerking vanaf SSD de voor de client zichtbare voltooiingstijd niet verkorten.

Het artikel over L2ARC-optimalisatie vermeldt ook dat sequentieel verkeer door vooruitlezen niet altijd naar L2ARC wordt gepromoveerd en dat leescache ineffectief is voor schrijfintensieve werklasten of datasets die veel groter zijn dan de cachehiërarchie. Daarom mag een cachebenchmark niet alleen een tweede kopie van één kleine map gebruiken om het resultaat vervolgens te veralgemenen naar streaming over meerdere terabytes.

Patroon bij meerdere gebruikers	SSD-leescache	Rechtstreekse schijftoegang	Waarschijnlijke winnaar
Meerdere gebruikers openen dezelfde veelgebruikte bestanden opnieuw nadat ze uit het RAM zijn verwijderd	Kan backend-zoekbewerkingen verminderen	Herhaalt HDD-werk	SSD-cache als de hitratio stabiel wordt
Gebruikers lezen eenmaal grote, niet-gerelateerde bestanden	Lage herbruikbare waarde	Efficiënt sequentieel pad	Rechtstreekse schijftoegang
Gedeelde dataset past in het RAM	Weinig extra waarde	Grotendeels omzeild door RAM	Geen van beide upgraden; het RAM-pad behouden
Clientnetwerk is verzadigd	Verandert de zichtbare snelheid mogelijk niet	Voedt de verbinding al	Los het netwerk alleen op als dat de echte beperking is
Veelgebruikte gegevens moeten bij elke toegang voorspelbaar snel zijn	Opwarmtijd en verwijdering blijven van belang	Te traag als de HDD de beperking vormt	Overweeg een speciale SSD-laag

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Cachethrashing kan de SSD-laag druk laten lijken zonder gebruikers sneller te maken

Een SSD-leescache moet worden gevuld, geïndexeerd en beheerd. Als de gecombineerde werklast voortdurend verandert, kunnen nuttige blokken worden verwijderd voordat een andere gebruiker ze opnieuw gebruikt. Het cacheapparaat kan dan zware activiteit tonen terwijl de HDD-pool nog steeds veel missers afhandelt. Daarom is SSD-gebruik op zichzelf geen bewijs van voordeel.

Een communitythread van TrueNAS uit 2025 beschrijft een gemengde NAS- en Proxmox-werklast waarbij de ARC-hitratio normaal hoog was, maar sterk daalde tijdens gebeurtenissen zoals het opnieuw opstarten van veel VM's, terwijl L2ARC een betekenisvol deel van de missers opving. Deze cachecase voor een gemengde werklast is nuttig als één reëel gebruikspatroon, niet als universeel streefgetal voor de hitratio.

De cache verliest aan waarde wanneer deze voortdurend thrast, schaars RAM verbruikt voor metadata of bijna evenveel kost als de bekende veelgebruikte dataset op een speciaal SSD-volume plaatsen. Een cache is adaptieve plaatsing; een speciale SSD-laag is expliciete plaatsing. Gebruik die laatste wanneer voorspelbare latentie belangrijker is dan automatische promotie.

Test gedeelde werklasten, niet één client die één map herhaaldelijk leest

Maak drie datasets: een gemeenschappelijke veelgebruikte set die door alle clients wordt gebruikt, een privéset per client en een sequentiële archiefset. Voer hetzelfde toegangsschema eerst zonder SSD-cache en daarna met SSD-cache uit. Registreer ARC-/paginacache-hits, SSD-cachehits, HDD-IOPS en -latentie, netwerkgebruik en de p95-responstijd voor clients. De cache moet het backend-schijfwerk voor de gemeenschappelijke set verminderen, niet alleen een snellere tweede uitvoering opleveren.

Maak productiecaches niet destructief leeg alleen om een benchmark te creëren. Gebruik een testdataset die groter is dan het beschikbare RAM, gecontroleerde herstarts waar dat passend is of runs die lang genoeg duren om de gemeenschappelijke set door de normale hiërarchie te laten bewegen. Vergelijk zowel stabiel gedrag na het opwarmen als koud gedrag, want een cache die langer nodig heeft om op te warmen dan de werklast duurt, heeft weinig praktische waarde.

Het bestaande ZimaSpace-artikel over de algemene cachebeslissing voor herhaalde leesbewerkingen beschrijft de grens van de werklast voor één gebruiker. Deze test voegt een afzonderlijke vraag toe: of verschillende gebruikers elkaars gecachete blokken vaak genoeg hergebruiken om het resultaat te veranderen.

Kies uit drie uitkomsten in plaats van cache tegenover geen cache te zetten

Kies SSD-leescache wanneer de gedeelde werklast niet in het RAM past, door meerdere gebruikers wordt herhaald, goed genoeg in de cachelaag past om stabiele hits op te leveren en de HDD-latentie daalt wanneer de cache actief is. Houd het bij rechtstreekse schijftoegang wanneer leesbewerkingen voornamelijk sequentieel of privé zijn, de pool al aan de latentiedoelen voldoet of het netwerk de zichtbare bovengrens blijft.

Kies een speciale SSD-dataset of een speciaal SSD-volume wanneer veelgebruikte bestanden onmiddellijk snel moeten zijn, vaak worden geschreven of te belangrijk zijn om afhankelijk te maken van promotie- en verwijderingsbeleid. Die derde optie is vooral relevant voor actieve VM-schijven, databases, containerstatus of projectbestanden met een duidelijk afgebakend veelgebruikt gedeelte.

De winnaar zou alleen moeten wisselen wanneer een gemeten voorwaarde wisselt: gedeeld hergebruik, geheugenmissers, backend-schijflatentie, stabiliteit van cachehits of beschikbare netwerkcapaciteit. Als geen van deze factoren verandert, is een SSD-cache gewoon nog een apparaat dat moet worden beheerd. Schaalvergroting naar meerdere gebruikers creëert alleen een cachekans wanneer die herhaalbare gedeelde leesbewerkingen oplevert.