Windows 10 averaging over 50GB of writes/day to SSD over 9months

resource-usagessdwindows 10

Update: Moving the following folders off drive then symlinking them eliminated the constant writing to C:.

  • %LocalAppData%\Google\Chrome – Easily the biggest consumer.
  • %LocalAppData%\Microsoft\Windows\FileHistory

I moved them to a freshly formatted drive. After 3 hours there has already been 10.5GB of reads and 10.3GB of writes. In that same time, Drive C:\ has only seen 3.5GB of reads and 1.3GB of writes.

This has been bugging me for a while. Windows 10 Education seems to constantly write data to the C:\ drive for no apparent reason, even when the PC goes unused for days at a time. I can't find the source of the writes or the data it writes.

In just 9 months 10% of the 500GB Samsung 850Evo's drive life has been consumed. Is this because Windows is doing a lot of logging and tracking in the background? If that's the reason, I'd like advice on how to disable it. I feel there's nothing else left that I could move off the C:\ drive (more on this in the breakdown)

HWInfo64 has been running the past 12.75 days(w/14-days uptime) to track drive stats. During this time the PC was not touched from July 1st to July 5th or July 8th. I figure the max possible time in use is about 5 days because during the weekdays it's sitting untouched for at least 18hrs.

Here's a breakdown of most of the drives:

  • 500GB Samsung 850Evo(Age: 0.7yr | HostWrites: 13.3TB(~50GB/day))

    • C:\ In past 2 weeks: Nothing new installed, but 900GB(64GB/day) was written. That's 180GB/day for 5 usage days. ShadowCopy(System Restore) is set to 10% and there is no FileHistory for this drive.

  • 500GB Samsung 850Evo(Age: 1.7yr | HostWrites: 8.6TB)

    • A:\ Important data and UserProfile folders are mapped here. This is the only drive with FileHistory enabled. ShadowCopy(System Restore) is set to 15%.
      This was once a Windows 7 C: drive for about a year.

  • 250GB Samsung 840Evo(Age: 3.7yr | HostWrites: 10.5TB) & 256GB Crucial m4(Age: 4.8yr | HostWrites: 25TB)

    • D:\ Drives are pooled to create a Stripped StorageSpace(raid0). The PageFile, TEMP folders, SoftwareDistribution, NodeJS/npm, Origin, Steam, and Recorded TV are stored here. There is no ShadowCopy(System Restore) or FileHistory for this drive.
    • Under Windows 7 each drive was a system drive at one time, the 840Evo for a year and the m4 for 3yrs. The m4 has just started failing in the last 30 days and will often drop offline during heavy writes. The HWInfo stats even show its not pulling it's weight. StorageSpaces manages the drive well enough that I haven't got around to removing the drive yet.
      This is after only 25TB of HostWrites in a 5yr period, the 850Evo is already half way there. This is the motivating factor behind this question.

  • 4TB HGST Deskstar(Age: 2.6yr | HostWrites: 17TB) & 4TB HGST Deskstar(Age: 0.75yr | HostWrites: 7TB)

    • B:\ & M:\ Drives are pooled to create a 2TB Stripped and a 3TB Mirrored StorageSpace respectively. Neither volume has FileHistory or ShadowCopy protection. Movies, Music, and etc. are stored on B:\n. M:\ is the backing store for all FileHistory with changed files being versioned and backed up to it every 10 minutes.

As you can see, Windows 7 wrote no wear near as much data. Here's a screenshot of HWInfo64.

HWInfo64 screenshot

Best Answer

You can use Task Manager to see what processes are writing the most data to disk.

Open Task Manager, select the Details tab, right-click on the table header, and click Select columns. Then check I/O read bytes, I/O write bytes, and I/O other bytes and click OK.

That said, I think File History is to blame here.

In my experience, the File History databases (Catalog1.edb and Catalog2.edb) can grow very large over time. To make matters worse, they are rewritten in their entirety every time the history is updated (every 10 minutes as configured on your system), and Windows will decompress them if you use NTFS compression. This can cause large amounts of writes to the disk over time.

Regardless of which drives are covered by File History, these databases are stored in your user profile at C:\Users\<username>\AppData\Local\Microsoft\Windows\FileHistory\Configuration. With a pair of 100 MB databases, nearly 30 GB a day will be written to the system volume at 10 minutes per update, assuming it writes both files every time.

My solution was to use a junction point. Stop the File History service, move the Configuration folder to another location where write endurance is not an issue, create a junction point that points to the new location in place of the original location of the folder, and restart the File History service. That should fix the problem.

Related Question