Now Reading
Firefox is eating your SSD – here is how to fix it
78

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

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.

Firefox Disk Writes

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:

Firefox Disk Activity Process Monitor

 

  • 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.

Firefox Disk Activity File Stats

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.

Firefox Disk Activity File Stats 2

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.)

About The Author
Sergei Bobik
Sergei is a solutions architect at a major US based apparel and retailing company.
78 Comments
  • Philip
    September 23, 2016 at 7:13 am

    Is there any indication that Thunderbird is doing this as well?

  • James
    September 23, 2016 at 8:00 am

    Thanks, Sergei. Observing similar behavior with:
    Vivaldi 1.5.609.8 (Developer Build) (32-bit). just looking at the I/O Write Bytes column in Process Explorer. Launched this Vivaldi session ~40 ago, some of the child processes (Twitter tabs?) have written as much as 1.4 GB to date.

  • Till
    September 23, 2016 at 8:10 am

    I cannot reproduce this while Firefox is idle. It seems that data is only written, when i change something in Firefox, e.g. if I scroll down a page i see a write a few seconds later. This makes total sense to me, as the session has changed.

    -> May it be, that some websites or plugins or you ff constantly change the session data? can you reproduce this problem without any plugins on simple html sites? I am also using u Block, maybe some updated banners or something like that cause a change?

    (I am using the Linux Version 45.4.0 (64 bit) o FF on Gentoo)

  • Eric
    September 23, 2016 at 8:27 am

    In looking at the parameters, it shows 15000 for the value, I’m guessing to multiply that by 4 to get the minute and then by 30 to get to 30 minutes for the refresh?

    • R Puig.
      September 23, 2016 at 3:34 pm

      That value is stored in milliseconds (1 second = 1000 ms). So, in order to change it to 30 minutes, you would do the following:

      (1000 * 60 * 60) * 30 = 108000000
      (1m) (f) (ms)

      Here’s the definition of those labels:
      ms = millisecond
      s = second
      m = minute
      h = hour
      d = day
      w = week

      And some constant values to help you along:
      1s = 1000 (base)
      1m = 1000 * 60 = 60000
      1h = 1000 * 60 * 60 = 3600000
      1d = 1000 * 60 * 60 * 24 = 86400000
      1w = 1000 * 60 * 60 * 24 * 7 = 604800000

  • September 23, 2016 at 8:34 am

    Hi, I’m one of the Firefox developers who was in charge of Session Restore, so I’m one of the culprits of this heavy SSD I/O. To make a long story short: we are aware of the problem, but fixing it for real requires completely re-architecturing Session Restore. That’s something we haven’t done yet, as Session Restore is rather safety-critical for many users, so this would need to be done very carefully, and with plenty of manpower.

    • Andy
      September 23, 2016 at 8:52 am

      Is there a setting to shut off this feature manually?

      Or do we need to increase the interval to ridiculous high values?

    • David
      September 23, 2016 at 12:26 pm

      Does Firefox also do this when you close it? Can I set it to a high interval and still be sure to get my session, assuming that Firefox has been closed properly the last time?

    • optimist
      September 23, 2016 at 11:11 pm

      Hi Yoric,
      thanks for chiming in on this.
      Is there an existing Firefox bug regarding this problem? If so, which ID does it have? Could you link it?
      Are there plans on Mozillas side, to address this issues. You describe that a fix is not trivial but at the same time it sounds like there is no active work happening ot the moment.
      I understand that with e10s being your main focus point, this may have to wait until after Firefox 51.

      Would appreciate more detail though. And thanks for the work you are doing at Mozilla!

  • Yoric
    September 23, 2016 at 8:35 am

    Of course, as usual in an open-source project, contributors would be appreciated 🙂

  • Andy
    September 23, 2016 at 8:37 am

    It would be great if you’d remind people that the unit of “browser.sessionstore.interval” is MICROSECONDS,
    If people set it to a value like “15” and not “15000” for a 15 second interval (default in FF), they might have a write every 15/1000 of a second, with far more devastating results!

    Hint: to set it to half an hour the correct value would be 1800000 = 1.800.000 (1.8 Million)

  • Tim Locke
    September 23, 2016 at 8:45 am

    I’m running Firefox 49 on Xubuntu 14.04 LTS and browser.sessionstore.interval is set to 15,000

  • enigmaxg2
    September 23, 2016 at 9:43 am

    “Cookie* files had a ton of data written to them, as before.”

    Should be good to see other browsers behavior and see it they do the same, I wouldn’t be surprised if all others do this, because it seems to be bound to sites abusing of javascript (intersitials, tracking) and therefore creating cookies.

  • manole
    September 23, 2016 at 10:55 am

    Another fix is to stop using Firefox.

    • enigmaxg2
      September 23, 2016 at 11:08 am

      Chrome is less offending with this issue (12GB/Day less than FF), but in the other hand it eats a lot of RAM making things slower, it’s time for all browser developers to revamp their creations and also this is a signal to websites to stop overusing scripts, they run several times per second so the “site” changes very often and new status must be -unnecesarily- written

  • che
    September 23, 2016 at 10:56 am

    Is this only on idiotic Windows System or on Linux too?

  • small-hint
    September 23, 2016 at 11:21 am

    Also see about:config browser.cache.disk.enable and browser.cache.capacity

  • Tom T
    September 23, 2016 at 11:26 am

    why are they not using a transaction logfile for the session? they would just append changes to the session and replay it on restore.

  • Kris
    September 23, 2016 at 12:30 pm

    I just run portable Firefox off my secondary, non-ssd harddrive. I don’t notice any performance issues and I try to run only games on my SSD.

  • Nils
    September 23, 2016 at 1:19 pm

    Does it flush after every white? Otherwise a lot of this should be mitigated by the OS filesystem cache.

  • Radr
    September 23, 2016 at 1:38 pm

    Since you observed lots of cookie data being written: were ads and/or tracking scripts being blocked (in-browser or via proxy or some other solution)?
    If not, this might be something interesting to try for comparison purposes.
    Related: using Firefox in private mode probably could be a workaround.

  • Roy
    September 23, 2016 at 3:06 pm

    The best suggestion is to turn session restore OFF.

    about:config
    browser.sessionstore.resume_from_crash to FALSE

    • John
      September 24, 2016 at 10:29 am

      I like this idea, and use the AddOn called Session Manager to restore any browsing session, including crashed browsing sessions.

  • Other Solutions
    September 23, 2016 at 3:21 pm

    Not sure I can get the link posted here, so I’ll write out the search: “Firefox on RAM – ArchWiki site:archlinux.org” (via HN).

    A few solutions, some slanted toward Linux but can be modified for other OSes. I’m going to experiment with the first option: Relocate cache only to RAM and give it a few MBs to see how this plays out. Session restore = not a big deal for me. I have an older computer (dualCore, older HD) and although I don’t ever see the HD’s LED flashing often (FF is pretty responsive), I don’t like the idea of my older SATA drive over-working.

  • Marc Diethelm
    September 23, 2016 at 4:59 pm

    Using uBlock Origin in Firefox and I’m not seeing any excessive disk writes. I recommend you use an adblocker as well.

  • Sebastian
    September 23, 2016 at 11:29 pm

    It should be said that SSD can take quite a beating. 10GB/day is not exactly too much.

    • Calibrator
      September 23, 2016 at 11:38 pm

      Yes, but if you aren’t only using the browser…

      Also, the question is if most people actually need a full session restore or if they are satisfied with a URL restore for each tab.
      For this the browser would only need to write whenever the URL of a tab is changed – which would result in much much less data.

  • Sponky
    September 24, 2016 at 2:54 am

    My two year old system drive (Samsung 840 Pro) has written 7.75TB. So making the very conservative assumption of a write endurance of 100TB the drive should be good for another 25 years at this rate.

    I think I’ll leave the default settings.

  • WB
    September 24, 2016 at 4:07 am

    I think you’re making a mountain out of a molehill.
    Although I think 15 seconds is quite on the paranoid side (then again, I think Mozilla expects Firefox to crash left right and center) it still wouldn’t matter in terms of lifetime of your SSD.

    Raw IO measurements will likely not indicate what is actually written to disk, to begin with, so your measurement is quite biased to the high side.
    Keep in mind: If you write 50GB of data every single day to an inexpensive 256GB SSD, without skipping a day, you can easily last the stated average lifetime for those disks (8 years) without it developing a problem (considering you don’t slam it chock-full of data and forcing it to over-use the same chips time and again). So, does a few MB more or less matter? Not really. Unless you’re the person who wants to buy a sports car to just have it sit in front of their house and not use it 🙂

  • Kougeru
    September 24, 2016 at 10:27 am

    I solved this by disabling the feature and using an add on that saves the sessions to Dropbox instead of my local ssd

  • John
    September 24, 2016 at 10:32 am

    There’s a Firefox Add-on called “Session Manager” which backs up any number of sessions you want. It also backs up a crash. I wonder if it uses a similar scanning protocol? If not, that’s the right way to backup sessions. I’ll check with the developer.

  • xs
    September 24, 2016 at 11:00 am

    firefox 45.4.0 ESR with µblock µmatrix and noscript.

    no problems

  • tukoz
    September 24, 2016 at 11:01 am

    Hey! I launched disk IO monitoring tool `iotop` in cumulative mode on my desktop right after reading this article today morning. Below are the results after tracking any single disk READ or WRITE today. Please note that my desktop SSD has a SandForce controller and I have just no idea whether iotop takes it compression in account or not.

    – Firefox Aurora v50 has been running for six hours, half of it being pretty active browsing with my current session of 190 tabs.
    – Slimjet (Chrome fork) was launched and running six time less or one hour long, 5′ of which where active and 3-5 tabs.
    – Thunderbird was also launched and running for one hour with automatic fetching of 5 IMAP accounts.
    – Last, my podcast client (with automatic fetching of new episodes) was launched and running for two hours.

    $ iotop -oPa

    PID DISK READ DISK WRITE> SWAPIN IO COMMAND
    6343 46.44 M 309.09 M 0.00 % 0.00 % firefox-aurora
    15342 38.04 M 90.58 M 0.00 % 0.01 % python2 /usr/bin/gpodder
    17062 76.27 M 59.71 M 0.00 % 0.01 % slimjet
    28931 97.32 M 8.75 M 0.00 % 0.00 % thunderbird

    So taken back to one then twenty four hour each, stats are as follow
    – Firefox (190 tabs): 7.74 MB reads and 51.51 MB writes per hour → 0.186 GB reads and 1.236 GB writes a day
    – Slimjet (3-5 tabs): 73.27 MB reads and 59.71 MB writes → 1.758 GB reads and 1.433 GB writes a day
    – Thunderbird (5 accounts): 97.32 MB reads and 8.75 writes →2.336 GB reads and 0.21 GB writes a day
    – Podcast client (a hundred shows): 19.02 MB reads and 45.29 writes →456 GB reads and 1087 GB writes a day.

    ‘browser.sessionstore.interval’ has been set on ten minutes even since I put an SSD in that box. ‘browser.bookmarks.max_backups’ to three for even longer.

    S.M.A.R.T. says my SanDisk Extreme SSD [1] has written 23 TB in 27632 hours.

    9 Power_On_Hours_and_Msec 0x0032 069 069 000 Old_age Always – 27632h+35m+20.000s
    177 Wear_Range_Delta 0x0000 000 000 000 Old_age Offline – 7
    241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always – 23459

    So?
    Given the measured endurance for even more budget and smaller SSD is of dozen of TB written [2], that the real amount of data physically written *may* be lower than what iotop reports by an order of a magnitude (both sessionstore and else files are heavily compressible text files) thanks to the SF “magic”, and last but not the least that all my data is backed up twice a day to an external destination, I’d say what’s the big deal of all this? Focusing on a single process is OK but not cool unless taking the others in account.

    For those of us using the most hackable main stream browser available, do our job and reduce its IO activity as we wish. Gain a 50 years SSD life expectancy if that’s what you want 😉 a higher battery life on our laptop and a (much) better reactivity by making full use of our available RAM. And think of these using another browser that can’t be hacked half of what Firefox (or Seamonkey, Pale Moon) can (e.g. using a couple of small utilities available for Linux I swear I could have FF write 10 MB or less per hour).

    [1]: SanDisk Extreme SSD (with then ubiquitous SF2281VB1-SDC) on Arch Linux.
    [2]: http://ssdendurancetest.com/

  • Jeremy
    September 24, 2016 at 1:03 pm

    You know a reaaally easy fix would be simply to delete Firefox and download chrome.

  • Aaron
    September 24, 2016 at 1:06 pm

    Is there any way to only create a session restore when the browser is closed? Without writing to your drive every x minutes?

  • freediverx
    September 25, 2016 at 9:33 am

    Any tests planned on Safari?

  • sheldonng
    September 25, 2016 at 7:21 pm

    Consumer-grade SSD write endurance, approximately 40TB, with 12GB each day, you can use more than 20 years…..

  • pasmel
    September 25, 2016 at 10:47 pm

    I think you may be looking at the wrong values, at Process Explorer column selection look for the Process Disk tab instead of Process I/O.

  • Freddy
    September 26, 2016 at 12:29 am

    I got 16GB of RAM, so I decided that FIrefox shouldn’t use my SSD for storage in the presence of plentiful fast RAM.

    browser.cache.disk.enable = false
    browser.cache.memory.enable = true

    Done.
    Sessionsrestore works fine, too.

  • This Site Sucks
    September 26, 2016 at 2:16 am

    Can this stupid site change the extremely misleading title?

    Chrome is writing 24GB and killing drives faster and yet you’re blaming Firefox?

    Is the author an idiot moron or what?

  • Aluminum
    September 26, 2016 at 11:50 am

    For a second I thought maybe everyone was crazy and some new undetected browser malware was in the wild because I see hardly any disk activity at all even with 15 tabs open,

    Then I remembered I run noscript along with ublockO. Don’t let every random newsblogmarketspamwhatever site connect to 200 extra domains (with a potentially infinite tree of domains from a subset of those) and run whatever code they all demand you run, after that the internet sucks a lot less.

  • NightHawk
    September 26, 2016 at 12:37 pm

    Thanks for investigating and publishing your findings. Have added the tweaks and, so far, all working as before. I am using Session Manager addon.

  • JoeyBeanz
    September 26, 2016 at 5:38 pm

    This doesn’t matter at all. Modern SSD’s have write lifespans in excess of 1,000 terabytes. Even if firefox was writing ten times the amount of data that it does, it would take 25+ years for it to cause drive failure.

    Really not worth disabling a useful function to stop something that wouldn’t have an effect on my drives until long after I’ve replaced them for something bigger/faster.

    Your SSD’s are fine, don’t worry about it.

  • Konstantin
    September 26, 2016 at 11:49 pm

    Browsers are the main piece of software we use today. To make sure everything goes well they have to use that ressources.
    Considering today’s SSDs which much higher TBW than expected from the manufacturer (Samsung ones get about 300-400 TB on expected 100 TB written before they mark single bits as unusable I read somewhere) disk utilisation not really that much of a problem…

  • John
    October 4, 2016 at 7:14 am

    Has anyone tested Opera?

  • coakl
    October 4, 2016 at 3:14 pm

    How do we turn off this SSD-killer on Chrome?
    I’ve set Chrome to start up with the cache directory pointing to a RAM drive. But I don’t think Chrome session store goes there.

  • James
    October 31, 2016 at 4:30 am

    Would be nice if someone updated their .admx\.adml files for Chrome and Firefox…

  • max
    November 16, 2016 at 7:48 am

    found same issue;
    can said only one firefox made something bad in last updates from spring to autumn;
    before years without any changes it don’t eat ssd and Ikeave it as is on work PC with small SSD;

    in end of summer found somethink eat ssd ~9-15 Gb per day;

    moved firefox from ssd to hdd via mklinks;

    later will try your option with session interval;

  • Steve Aktkins
    November 24, 2016 at 3:52 am

    @ R Puig.
    September 23, 2016 at 3:34 pm

    Thanks a lot, you are the god of numbers.

    This what i was going to calculate but would not going so far, excellent!
    ****************************************************************************
    (1000 * 60 * 60) * 30 = 108000000
    (1m) (f) (ms)

    Here’s the definition of those labels:
    ms = millisecond
    s = second
    m = minute
    h = hour
    d = day
    w = week

    And some constant values to help you along:
    1s = 1000 (base)
    1m = 1000 * 60 = 60000
    1h = 1000 * 60 * 60 = 3600000
    1d = 1000 * 60 * 60 * 24 = 86400000
    1w = 1000 * 60 * 60 * 24 * 7 = 604800000

  • Steve Aktkins2
    November 24, 2016 at 3:57 am

    But 30 minutes are not 108000000
    but 3600000
    (1000ms*60)= 60000 (1 minute)
    (1000*60*30)=3600000 (30 minute)

    1h = 1000 * 60 * 60 = 3600000
    2h= 7200000

  • Phil
    December 11, 2016 at 10:34 am

    Well… thanks for all this information. I did learn a few tricks/things. Was appreciated!

  • coth
    December 15, 2016 at 8:32 pm

    All browsers writes cookies a lot while watching YouTube. It saves your position about every some time. Takes around 3 mb of cookies per minute. But could be much larger to SSD, as those writes are much smaller than 4 kb.

  • coth
    December 15, 2016 at 8:34 pm

    Unsure about html5 video cache, but could be also a serious issue. I set disk cache to off for Firefox.

  • checo
    December 28, 2016 at 2:52 am

    What will happen if you set firefox not to remember history, and not to accept cookies?

  • David
    February 12, 2017 at 4:28 pm

    You can’t really have it both ways; you want the speed so you have the files regularly accessed on the SSD, but think about it, do you NEED this?

    It is a bit like thw Windows page file, I always move it to a dedicated logical partiion.

    You can and SHOULD move your Windows profile location from the SSD to another drive, this page says how

    “The default location of user profile in Windows 7 is still the same as Vista, in c:\users folder, which I often find it seems quite dumb putting user profiles in the same partition as the system, especially when I store most of my day-to-day files in my user profile, rather than another folder in another partition. So my preference of the first step after installing the OS on my own computer is always to change the default location to another partition before I actually start setting up my profile.”

    https://www.nextofwindows.com/how-to-change-user-profile-default-location-in-windows-7

    This page tells you how to do it in Windows 10

    https://www.tenforums.com/tutorials/1964-users-folder-move-location-windows-10-a.html

Leave a Response