Firefox is eating your SSD – here is how to fix it

If you are a user of Firefox we have a must-change setting. Today’s modern multi-core processor systems and higher quantities of RAM allow users to open multiple Firefox tabs and windows simultaneously. This can have an unintended effect for those SSDs as session store data can write data constantly to NAND. This issue is being discussed in a STH forum thread where you can follow the discussion.

Observing the Issue: Heavy SSD Writes from Firefox

Purely by chance, I fired up a free copy of SSDLife on two consecutive days where I haven’t really used my workstation for anything other than email and browsing. For those of you unfamiliar with this tool, it simply reports estimated lifetime for the attached SSD and it also shows the amount of data read and written.

In my case, SSDLife notified me that 12GB was written to the SSD in one day. Since I didn’t recall downloading any huge files over the previous day or visiting any new sites that could’ve resulted in bringing down a lot of new content to the cache, this puzzled me. I monitored these stats over the next couple of weeks and this behavior stayed consistent. Even if the workstation was left idle with nothing running on it but a few browser windows, it would invariably write at least 10GB per day to the SSD.

firefox-with-32gb-written-in-a-single-day

To find out what’s going on, I fired up Resource Monitor and looked at disk utilization.

At the very top of the list was Firefox, writing tirelessly at anywhere between 300K and 2MB per second to a file called “recovery.js”. Researching revealed that this is Firefox’s session backup file that is used to restore your browser sessions in case of a browser or an OS crash. That is extremely useful functionality. I was aware of the fact that Firefox had this feature, but I had no idea that session information was so heavy!

Researching the issue a bit more over the next day, I discovered that things are worse than I originally thought and “recovery.js” isn’t the only file involved. In case someone wants to replicate, here’s what I did this morning:

• I reset browser.sessionstore.interval to 15000 and then got rid of all my currently open FF windows.
• I opened a single window with just Google running in it, left it sitting for a couple of minutes, and then closed it.
• I started the browser again and on this final restart the recovery.js file was only 5KB in size, down from around 900KB before.
• Next, I opened a bunch of random reviews for Samsung 850 pro and Samsung Galaxy S7 in two separate windows. Simply searched for “samsung 850 pro review” and “samsung galaxy s7 review” and then went down the list of results opening them in new tabs.
• I opened a 3rd window and created a bunch of tabs showing front pages for various news sites.
• I launched Process Monitor and configured it to track recovery.js and cookie* files:

• I went to File->Capture Events and disabled it. Cleared all events that were currently showing up.
• I went back to File->Capture Events and re-enabled it. Left the three FireFox windows sitting idle for 45 minutes while I was using Chrome instead.
• Then I went to Tools->File Summary to get overall stats.
• Firefox managed to write 1.1GB to disk with the vast majority of data going into cookie* files.

Note that recovery.js managed to accumulate only about 1.3MB of writes.

I went back to one of the Firefox windows and opened my outlook.com mailbox. Cleared all events in Process Monitor and re-started the capture. Again, I left all Firefox windows sitting idle, but only for ~10 minutes. This time recovery.js was at ~1.5MB and it took only about 1/4-th of the time to get there. Cookie* files had a ton of data written to them, as before.

Depending on what you’ve got open in your tabs, Firefox could be dumping tons of data into recovery.js, cookie* files, or both. Running at 1.1GB for every 45 minutes, you’re looking at ~35GB/day written to your SSD if you leave your machine running. And at least in my case this wasn’t even the worst example of how much data could be going into recovery.js. In my original tests I clocked Firefox at 2MB/s writing to this file and the writing thread never went dead always showing up on the top of the list in Resource Monitor.

The Easy Fix

After some digging, I found out that this behavior is controlled by a parameter that you can access through typing “about:config” in the address bar. This parameter is called: —browser.sessionstore.interval

It is set to 15 seconds by default. In my case, I reset it to a more sane (at least for me) 30 minutes. Since then, I’m only seeing about 2GB written to disk when my workstation is left idle, which still feels like a lot but is 5 times less than before.

Bottom line is that if you have a lower capacity consumer level SSDs in some of your machines, you may want to check and tweak your Firefox config. Those drives can be rated for about 20GB of writes per day and Firefox alone might be using more than half of that. This is especially true if you’re like me and have a several browser windows open at all times each with numerous tabs. Changing this parameter may even help with normal HDDs. Your machine will feel faster if it doesn’t have to constantly write this session info. We have seen in the STH forum thread that content open in browser does have a major impact on writes as does the number of open windows and tabs. If you are using Firefox and a lower write endurance SSD you should check this immediately.

If you are wondering how this compares to real-world enterprise SSD usage, STH did a study buying hundreds of used enterprise/ datacenter SSDs off of ebay and checking SMART data for actual DWPD usage. See: Used enterprise SSDs: Dissecting our production SSD population

Update 1: We are testing other browsers. Currently in the middle of a Chrome Version 52.0.2743.116 m test. We have been able to see a pace of over 24GB/ day of writes on this machine (see here.)