The topic I checked how much data Windows had written to my SSD — I wasn’t ready for what… is currently the subject of lively discussion — readers and analysts are keeping a close eye on developments.
This is taking place in a dynamic environment: companies’ decisions and competitors’ reactions can quickly change the picture.
I’ve used CrystalDiskInfo for years on different computers to check the health status of my SSDs. Typically, when I open it and see the usual “Good,” I’m content enough to close it and carry on with other tasks. But this time, the total data written caught my eye. It was at 40513GB, simply far higher than I expected, and with no extra context, it felt like I was burning through my SSD’s lifespan very quickly.
This inspired some deep research. I discovered Windows measures SSD endurance in TBW (terabytes written) but rarely exposes that raw number. What was more surprising was that a large portion of the writes did not come from actions I had taken. They were mainly background Windows activities.
On CrystalDiskInfo, this data is labeled as Total Host Writes. It’s an element of the drive’s SMART data, a kind of internal telemetry it holds about itself. Even though it’s continuously logged, it’s not presented in any user-facing way. Once you open the tool, it displays a table of relevant drive attributes, and here are some attributes you should pay attention to:
The number of writes was already about 40.51TB. This figure became more significant when I looked up the SSD’s rated TBW on the manufacturer’s product page. With these figures, I could calculate how much of my SSD’s lifespan is left using a simple formula: Percent of rated lifespan used = (Total Host Writes ÷ TBW) × 100.
For perspective, the average user writes between 7–15TB per year, while consumer SSDs are rated at 300–600TBW. for example, a 1 TB drive rated at 600 TBW could last decades (roughly 40 years at typical consumer write levels), which implies that endurance wouldn’t be the factor that ends the drive. The number I had seen for my SSD still felt high even with this context.
Some budget or older drives may not surface some of these details, not even on CrystalDiskInfo.
I panicked when I saw the large write number. Even though this may be understandable, that panic was misplaced. TBW is not a hard expiry date, but more of a warranty-backed threshold. It’s the manufacturer simply guaranteeing a certain amount of data the drive will handle under normal conditions. However, SSDs will generally exceed this limit significantly, mainly because NAND cell degradation is a very gradual process, and writes generally get evenly distributed across the drive by wear leveling.
From the above comparison, budget drives typically have a much lower TBW rating than mid-range options. This is an important detail if you plan to keep the drive for a long time. However, performance doesn’t degrade as you approach the TBW limit; it typically remains stable until cells actually fail. And that was the point that made the figures I saw for my drive less alarming. Even if a drive hits 85% of its rated endurance, its performance will remain identical to a newer drive carrying out normal tasks.
The Samsung 870 EVO is a high-performance 2.5-inch SATA III internal solid-state drive (SSD) designed for consumers, creators, and IT professionals.
The figures I saw were surprising, especially because I felt I hadn’t done any activities out of the ordinary. But that’s explained by the write traffic that Windows generates, totally independent of your activity.
Hibernation (hiberfil.sys) has the highest impact. When your PC hibernates fully, Windows writes nearly your entire RAM contents to disk. Fast Startup, which most Windows 11 machines use by default, works differently: it only hibernates the kernel session rather than your full RAM, producing a smaller file that typically lands around 40% of your installed RAM. On a 16GB system, that’s still roughly 6GB written every time you shut down.
Pagefile (virtual memory) also has a high impact. Windows uses the pagefile for virtual memory and manages its size dynamically. This file is constantly expanding and shrinking because of memory pressure, and that process generates significant background writes.
There is also some meaningful impact from the Windows Update cache. These are infrequent writes but can be as large as several gigabytes for major updates. Additionally, system Restore / Volume Shadow Copy (VSS) produces a reasonable number of writes.
Windows Search indexing produces some writes, and so does SysMain (Superfetch), even though the impact of these isn’t as much. With this understanding, it became clear why my system had recorded as much as 40TB of write.
Disabling background services is unnecessary and unrealistic for most drives. So I turned my attention to making changes that affect activities with the highest write volumes. This included totally disabling hibernation. This feature is not really needed on a desktop that never runs on battery, and you only have to run the command powercfg /h off on an elevated command prompt to turn it off.
I didn’t disable Search indexing, but narrowed it down to only folders I search in, like Documents and the Start Menu. However, I left SysMain untouched. I also kept VSS because it’s too much of a trade-off to lose restore points. Of all the changes, disabling hibernation is the most consequential because it writes the most to the SSD.