Ik heb gecontroleerd hoeveel data Windows naar mijn SSD had geschreven — ik was niet voorbereid op wat ik vond

Ik gebruik al jaren CrystalDiskInfo op verschillende computers om de gezondheidstoestand van mijn SSD's te controleren. Gewoonlijk, wanneer ik het open en het gebruikelijke 'Goed' zie, ben ik tevreden genoeg om het te sluiten en door te gaan met andere taken. Maar deze keer trok de totale hoeveelheid geschreven gegevens mijn aandacht. Het stond op 40513 GB, gewoon veel hoger dan ik had verwacht, en zonder extra context voelde het alsof ik de levensduur van mijn SSD erg snel aan het opbranden was.

Dit inspireerde tot wat diepgaand onderzoek. Ik ontdekte dat Windows de duurzaamheid van SSD's meet in TBW (terabytes geschreven), maar dat dat ruwe getal zelden wordt blootgegeven. Wat nog verrassender was, was dat een groot deel van de schrijfacties niet afkomstig was van handelingen die ik zelf had uitgevoerd. Ze kwamen voornamelijk van achtergrondactiviteiten van Windows.

Hoe ik de totale schrijfacties van mijn SSD heb gecontroleerd

Het nummer dat Windows bijhoudt maar je nooit laat zien

In CrystalDiskInfo wordt deze gegevens aangeduid als Total Host Writes. Het is een onderdeel van de SMART-gegevens van de schijf, een soort interne telemetrie die het over zichzelf bijhoudt. Hoewel het continu wordt geregistreerd, wordt het nergens op een voor de gebruiker zichtbare manier gepresenteerd. Zodra je de tool opent, wordt een tabel met relevante schijfkenmerken weergegeven, en hier zijn enkele kenmerken waar je op zou moeten letten:

Het aantal schrijfacties was al ongeveer 40,51 TB. Dit cijfer werd nog significanter toen ik de TBW van de SSD op de productpagina van de fabrikant opzocht. Met deze cijfers kon ik berekenen hoeveel van de levensduur van mijn SSD nog over is met een eenvoudige formule: Percentage van de geapprecieerde levensduur gebruikt=(Totale hostschrijfacties ÷ TBW) × 100.

Ter perspectief: de gemiddelde gebruiker schrijft tussen de 7 en 15 TB per jaar, terwijl consumenten-SSD's worden beoordeeld op 300-600 TBW. Bijvoorbeeld, een 1 TB-schijf die is beoordeeld op 600 TBW zou tientallen jaren mee kunnen gaan (ongeveer 40 jaar bij typische consumentenschrijfniveaus), wat impliceert dat duurzaamheid niet de factor zou zijn die de schijf doet stoppen. Het cijfer dat ik voor mijn SSD had gezien, voelde nog steeds hoog aan, zelfs met deze context.

Het cijfer ziet er eng uit, maar dat is het meestal niet

Waarom de duurzaamheid van SSD niet werkt zoals de meeste mensen denken

Ik raakte in paniek toen ik het grote schrijfgetal zag. Hoewel dit begrijpelijk kan zijn, was die paniek niet terecht. TBW is geen harde vervaldatum, maar meer een door de garantie ondersteunde drempel. Het is de fabrikant die simpelweg een bepaalde hoeveelheid data garandeert die de schijf onder normale omstandigheden kan verwerken. SSD's zullen deze limiet echter over het algemeen ruim overschrijden, vooral omdat de degradatie van NAND-cellen een zeer geleidelijk proces is en schrijfbewerkingen over het algemeen gelijkmatig over de schijf worden verdeeld door wear leveling.

Ik heb een vergelijking gemaakt van verschillende consumentenschijven:

Uit de bovenstaande vergelijking blijkt dat budgetschijven doorgaans een veel lagere TBW-classificatie hebben dan middenklasseopties. Dit is een belangrijk detail als je van plan bent de schijf lange tijd te behouden. De prestaties verslechteren echter niet naarmate je de TBW-limiet nadert; ze blijven meestal stabiel totdat de cellen daadwerkelijk falen. En dat was het punt dat de cijfers die ik voor mijn schijf zag minder verontrustend maakte. Zelfs als een schijf 85% van zijn geclassificeerde duurzaamheid bereikt, blijven de prestaties identiek aan die van een nieuwere schijf bij het uitvoeren van normale taken.

Waar al die schrijvers eigenlijk vandaan komen

Windows is nooit echt inactief

De cijfers die ik zag waren verrassend, vooral omdat ik het gevoel had dat ik geen activiteiten buiten het gewone had gedaan. Maar dat wordt verklaard door het schrijfraffic dat Windows genereert, volledig onafhankelijk van jouw activiteit.

Sluimerstand (hiberfil.sys) heeft de grootste impact. Wanneer je pc volledig in sluimerstand gaat, schrijft Windows bijna de volledige inhoud van je RAM naar de schijf. Fast Startup, dat standaard door de meeste Windows 11-systemen wordt gebruikt, werkt anders: het sluimert alleen de kernelsessie in plaats van je volledige RAM, waardoor een kleiner bestand wordt geproduceerd dat meestal rond de 40% van je geïnstalleerde RAM ligt. Op een systeem met 16 GB is dat nog steeds ongeveer 6 GB die elke keer wordt weggeschreven wanneer je afsluit.

Het wisselbestand (virtueel geheugen) heeft ook een grote impact. Windows gebruikt het wisselbestand voor virtueel geheugen en beheert de grootte ervan dynamisch. Dit bestand breidt zich voortdurend uit en krimpt door geheugenbelasting, en dat proces genereert aanzienlijke achtergrondschrijfacties.

Er is ook enige betekenisvolle impact van de Windows Update-cache. Dit zijn zeldzame schrijfbewerkingen, maar kunnen zo groot zijn als enkele gigabytes voor grote updates. Daarnaast produceert Systeemherstel/Volume Shadow Copy (VSS) een redelijk aantal schrijfbewerkingen.

Windows Zoeken-indexering veroorzaakt enkele schrijfbewerkingen, en dat doet SysMain (Superfetch) ook, hoewel de impact hiervan niet zo groot is. Met dit inzicht werd duidelijk waarom mijn systeem tot wel 40TB aan schrijfbewerkingen had geregistreerd.

De aanpassingen die echt een verschil maakten—and de dingen die ik met rust liet

Het uitschakelen van achtergrondservices is voor de meeste schijven onnodig en onrealistisch. Daarom heb ik mijn aandacht gericht op het aanbrengen van wijzigingen die activiteiten met de hoogste schrijvingsvolumes beïnvloeden. Dit omvatte het volledig uitschakelen van de slaapstand. Deze functie is eigenlijk niet nodig op een desktop die nooit op batterij werkt, en je hoeft alleen het commando powercfg /h off uit te voeren in een verhoogde opdrachtprompt om het uit te schakelen.

Ik heb de zoekindexering niet uitgeschakeld, maar heb het beperkt tot alleen de mappen waarin ik zoek, zoals Documenten en het Startmenu. Ik heb SysMain echter ongemoeid gelaten. Ik heb ook VSS behouden omdat het te groot is om herstelpunten te verliezen. Van alle wijzigingen is het uitschakelen van de slaapstand het meest ingrijpend omdat het het meest naar de SSD schrijft.