[Mr Alpha]

I got curious about where the writes to an SSD really comes from. So the other day I setup Process Monitor to capture a trace of all writes to my SSD and left it running for 24 hours (in reality 24 hours and 16 seconds). There was some surprises in there so I thought I would share my results.


The Setup
i5-2500k@4.7GHz on a P8P67 with 16GB DDR3-1333 RAM.
Radeon HD 5970@850/1100MHz
Intel 320 300GB SSD plus various hard drives.

I have moved My Documents, My Music, My Pictures, My Videos and Spotify’s cache folder to a hard drive. Windows, all programs, all games are installed on the SSD. Except for what I moved all user profile stuff (appdata and such) is on the SSD.

I avoided doing anything crazy that would produce a lot of writes like Virtual Machines, Mathematica or Bitcoin. Mostly what I did was surf with Firefox, play BF3 and fiddle with what I am supposed to be working on in Word. I had a x264 encode running in the background but it did all its reading and writing to a hard drive.

The memory usage stayed modes throughout the test, around 5 GiB.


The Results
Total amount of data written was: 26.6816 GiB

I made a bar chart of the processes that wrote the most. It is cut off at 50 MiB.

System comes out at the top of the list. This did not surprise me. I was expecting windows to be the biggest writer.

Firefox on the second place did surprise me though. The amount of writes it put out is almost the same as System. Also, I should mention that I have moved the Download folder to a hard drive so any download I’ve done is not part of the writes seen here.

In third place is carboniteservice.exe. That this one did lot of writes did not surprise me. It is my cloud backup solutions and I have it liberally updating everything in my user folders so it constantly needs to make note of what has changed and needs to be updates.

Chrome did more writes than I was expecting. I do all my surfing on Firefox because of its better handling of large amounts of tabs. The only thing I had open in Chrome was BF3’s battlelog since I’ve had some problems with it in Firefox Aurora.

Volume Shadow Copy Service, vssvc.exe, did produce some writes but not anything exceptional.

MsMpEng.exe is Windows Security Essentials, Microsoft’s free Antivirus solution. That it produced a bunch of writes is not a surprise. It is still quite modest.

That CCC.exe, Catalyst Control Center, show up amongst the top writers was a surprise. It only wrote to two locations: C:\ProgramData\ATI\ACE\Profiles.xml and C:\Users\admin\AppData\Local\ATI\ACE\Profiles.xml. I have no idea why it is doing this.

Spotify still did end up producing some writes to the SSD even though the cache was moved to a hard drive. I was playing Spotify a good chunk out of the 24 hour test.


The Details
I made a chart of the most written to files of System in hopes of figuring what it was doing. It is cut off at 100 MiB:

The thing that dominates this chart is the pagefile. At no time during this test was I memory constrained. I seems like Windows does make extended use of the pagefile even when it has gobs of RAM to work with. Not what I was expecting.

Many of the other locations written to by System are the same as written to by Firefox, Chrome, CCC and Spotify. Some sort of management maybe?
Then there is the $LogFile, $Mft and $BitMap, which all are part of the NTFS structures. For the record the total writes by all processes to those three is 1349.52 MiB.

I also made a similar chart of the most written to locations by Firefox. This one is also cut off at 100MiB:

The session file tops the chart. This immediately gives a clue as to what is causing Firefox to write so much. Eyeballing the trace it looks like firefox is writing the session to disk every 30 seconds or so. Crash recovery! Firefox will restore a session after a crash. In order to do that it has to write the session to disk. It apparently does this every 30 seconds, and combine this with the fact that I have a large session of 100+ tabs this means ~1.5 MiB of writes every 30 seconds.

Writes to the SQLite database files for cookies, webappstore, places and urlclassifier happen on the same frequency, presumably as part of the crash recovery as well.

Since writes to the cache by Firefox is spread out over multiple files it would not show up in this chart. So I added up all the writes to the cache folder, and that is 165.54 MiB. Not a significant part of total writes.


I found this interesting so I thought I should share.

[diaz]

Fantastic writeup. You have class sir.


Definitely gives you an insight as to what settings are useful or not on your browser..

Just not sure what can be done about the pagefile. Maybe it has to do with the browser activity as well. Pagefile is pretty much non-negotiable

[MattNo5ss]

Nice job and very informative

Looks like it's a good thing I don't use a pagefile and have crash recover off in FireFox

[diaz]

Crash recover still runs in the background on some browsers even when the option is disabled..

[Mr Alpha]

Bonus Chart:

In this chart I simply counted the number of individual writes of each size. This is out of a total of 1 434 592 writes. I should mentions that roughly half of the writes done actually matched up cleanly with the power of two numbers in the chart. What I've done is add them up, so that, for example the 4 KiB bar includes all writes from 2049 bytes (2 KiB +1B) up to 4096 bytes (4KiB exactly).

Interestingly enough there were 5 writes which were 0 bytes. I'm not quite sure what the point of them were.

The 0.5 KiB column is quite high but there were only 23 713 (~7.8%) writes that were exactly 512 bytes. Most were a lot smaller. The average size was 90.636 KiB.

The other extreme is the 4 KiB size where 534 915 (~95%) were exactly 4096 bytes. This was also by far the most common write size.

32 KiB was the size used by Firefox when doing its session backup so that is why that column is so big.

The single biggest write was 41 639 936 bytes or 39.7109 MiB.

[EarthDog]

Excellent information Mr A... thanks for that!

[Mr Alpha]

Second bonus chart. This one is interesting, but it does suffer from some methodological shortcomings.

What I've done is to try and estimate the ratio of sequential to random writes. I've defined a sequential write as one where it starts off from where the previous write ended. Random writes are defined simply as those writes that aren't sequential.

I've classified sequential writes in the data as those writes where the write is to the same file as the previous write and the write's offset is equal to the previous file's offset plus the length of the write.

One problem with this is that it will miss sequential writes where one write is to the end of one file and the following write is to the beginning of the next file. But I do not think this is a common case and so is not significant.

The bigger problem is the assumption that the files are laid out linearly, ie that they aren't fragmented. In reality files on an SSD likely are fragmented and so the number of random writes is higher. So what I present really is the amount of random writes I would have had had the drive been perfectly defragmented.

[Mpegger]

Originally Posted by Mr Alpha

I got curious about where the writes to an SSD really comes from. So the other day I setup Process Monitor to capture a trace of all writes to my SSD and left it running for 24 hours (in reality 24 hours and 16 seconds). There was some surprises in there so I thought I would share my results.

The Results
Total amount of data written was: 26.6816 GiB

At least I know I'm not going crazy.

I've made a post or two about the amount of writes my main OS/Drive drive gets, in the hope of getting help moving the writes off the SSD onto a mechanical drive to help preserve its life, once I install it with a fresh install of Windows as well. Most seem to still think that average daily writes for average usage is somewhere around the single digit GiB range and tell me not to worry, and that's without moving anything to a mechanical drive, such as the \Users or \Temp. Here I sit with my main OS/Data drive hovering around 113GB average writes per day, and almost 7.95TB total since I started keeping track back on 11/7/2011, and I get the sense that my post is just being looked at like there's something wrong with my totals.

[Mr Alpha]

Originally Posted by Mpegger

At least I know I'm not going crazy.

I've made a post or two about the amount of writes my main OS/Drive drive gets, in the hope of getting help moving the writes off the SSD onto a mechanical drive to help preserve its life, once I install it with a fresh install of Windows as well. Most seem to still think that average daily writes for average usage is somewhere around the single digit GiB range and tell me not to worry, and that's without moving anything to a mechanical drive, such as the \Users or \Temp. Here I sit with my main OS/Data drive hovering around 113GB average writes per day, and almost 7.95TB total since I started keeping track back on 11/7/2011, and I get the sense that my post is just being looked at like there's something wrong with my totals.

Since I got my drive in May 2011 I've totaled 20.5 TiB of writes. That makes an average of ~85GiB per day. And I know I was averaging north of 100GiB per day for a while there so I don't find your totals unbelievable. With a good SSD I still don't worry.

[Mpegger]

Originally Posted by Mr Alpha

Since I got my drive in May 2011 I've totaled 20.5 TiB of writes. That makes an average of ~85GiB per day. And I know I was averaging north of 100GiB per day for a while there so I don't find your totals unbelievable. With a good SSD I still don't worry.

Have you moved anything off the SSD during Windows install, such as the \Temp, \Users, or \ProgramData? I plan on moving at the very least the \Temp folders off the SSD, and more likely then not, then \User folder as well.

[Mr Alpha]

Originally Posted by Mpegger

Have you moved anything off the SSD during Windows install, such as the \Temp, \Users, or \ProgramData? I plan on moving at the very least the \Temp folders off the SSD, and more likely then not, then \User folder as well.

Nope. The only thing I've moved is the documents, pictures, videos and music folder as well as the spotify cache.

Here is a chart of the number of writes I had to those three paths:

Since the Firefox profile is in AppData under the user profile all Firefox's writes went to /User. /Windows/Temp had practically no writes at all, and /ProgramData was modest.

[notJUSTguitar]

Thanks for posting this...interesting.
I always use firefox and leave it open all day. Wouldn't ever think it was writing that much to my SSD!

[ziggo0]

Guess this is why I see a lot of SSD guides recommend moving the firefox cache off the SSD.

[Randyman...]

Originally Posted by Mr Alpha

Since I got my drive in May 2011 I've totaled 20.5 TiB of writes. That makes an average of ~85GiB per day. And I know I was averaging north of 100GiB per day for a while there so I don't find your totals unbelievable. With a good SSD I still don't worry.

Agreed 100%. I ran my pair of X25M G1's in RAID-0 for well over 2 years with everything running off it (minus my multiple TB of Data Files). Page file & everything. While I haven't checked the total useage, I know it is pretty high. Yet the drives still run like new after a Secure Erase now and again.

Bottom line? I'm not worried about "wearing out" my SSD's in the slightest. And I CERTAINLY would NEVER ponder moving my Page File or any Cache to a mechanical drive when my system has SSD's in it!!! That's tossing out the baby with the bathwater

A Descent SSD running everything under the sun = No Worries for years and years to come...

Nice legwork none-the-less!!!

[Brando]

I've been using firefox every day on my vertex 3 that I got on the first day of release plus installing\uninstalling games. It's still at 100% health according to the ocz toolbox thingamajig. Don't trip!

[Mr Alpha]

Originally Posted by Brando

I've been using firefox every day on my vertex 3 that I got on the first day of release plus installing\uninstalling games. It's still at 100% health according to the ocz toolbox thingamajig. Don't trip!

Well with a Vertex 3 you are in a very good position since it does compression and dedupllication. The session is stores as json in a textfile, and text compresses really well. My 1.7 MiB sessionstore.js file compresses down to 145 KiB. Add to that the fact that your session probably stays mostly the same in 30 seconds so it is mostly the same data being written. This allows SandForce to avoid writing most of it by simple deduplication. So for you running Firefox probably doesn't have any measurable effect on the lifespan of the SSD.

Originally Posted by ziggo0

Guess this is why I see a lot of SSD guides recommend moving the firefox cache off the SSD.

As I mentioned, out of the 9899 MiB written by Firefox, only 165.54 MiB (or 1.7%) were written to the cache. So I would say moving the Firefox cache is rather pointless. It would make a lot more sense to move the Firefox profile.

[EarthDog]

While making sense is one thing... is it necessary to move ANYTHING off your SSD these days?

I mean outside of this method:

Install W7
Install Chipset drivers
reboot
Install VGA drivers
reboot
Run WEI (shows system its an SSD and disables several items for the drive like defrag, indexing, etc)
If you need more space, shrink PF...if you dont hibernate/ system restore delete those files, and stop that from happening.

Is there any other maintenance that should be done for a modern SSD?

[Mr Alpha]

Originally Posted by EarthDog

While making sense is one thing... is it necessary to move ANYTHING off your SSD these days?

I would say no. Which is why I haven't moved anything off of my SSD beyond space saving stuff. My iTunes library is on a hard drive, not because I'm worried about writes, but not to waste SSD space on podcasts.

[bing]

Mr.Alpha, how much in percentage did pagefile.sys consumed for write ? Since you have the spreadsheet for those numbers and easier to calculate it.

[johan851]

Very nice investigation! I'm glad you did this.

The thing that dominates this chart is the pagefile. At no time during this test was I memory constrained. I seems like Windows does make extended use of the pagefile even when it has gobs of RAM to work with. Not what I was expecting.

This isn't terribly surprising, actually. When Windows writes to the pagefile it's not necessarily taking that information out of memory. It's just writing in anticipation of having to page something out. The page will likely stay memory resident for use later unless something kicks it out. If everything's idle, it makes sense from a performance standpoint to prepare for disk swapping so that if it happens the system is less likely to grind to a halt.