
Heavy SSD Writes from Firefox - kungfudoi
https://www.servethehome.com/firefox-is-eating-your-ssd-here-is-how-to-fix-it/
======
lighttower
Chrome, on my system, is even more abusive. Watch the size of the
.config/google-chrome directory and you'll see that it grows to multi-GB in
the profile file.

There is a Linux utility that takes care of all browsers' abuse of your ssd
called profile sync daemon, PSD. It's available in the debian repo or [1] for
Ubuntu or [2] for source. It uses `overlay` filesystem to direct all writes to
ram and only syncs back to disc the deltas every n minutes using rsync. Been
using this for years. You can also manually alleviate some of this by setting
up a tmpfs and symlink .cache to it.

[1]
[https://launchpad.net/~graysky/+archive/ubuntu/utils](https://launchpad.net/~graysky/+archive/ubuntu/utils)
[2] [https://github.com/graysky2/profile-sync-
daemon](https://github.com/graysky2/profile-sync-daemon)

EDIT: Add link, grammar

EDIT2: Add link to source

~~~
lucb1e
Launchpad is such a shitty website, aimed at Ubuntu and only Ubuntu, links to
source code or more information are nowhere to be found...

Searching on Github, this seems to be it. Turns out, there's releases for
Arch, Debian, etc. and it's even in the repositories. No need to add a ppa.
[https://github.com/graysky2/profile-sync-
daemon](https://github.com/graysky2/profile-sync-daemon)

For Debian and co:

    
    
        $ apt-cache show profile-sync-daemon
        $ sudo apt-get install profile-sync-daemon

~~~
matt4077
I checked the Activity Monitor on OS X to see if it's the same and if I should
do something. It's quite surprising:

    
    
        bird	         11,38 GB   119,8 MB		
        kernel_task	          8,82 GB    23,0 MB
        launchd	          8,46 GB    77,7 MB	
        revisiond	          8,35 GB   105,8 MB	
        Tweetbot	          3,01 GB    50,2 MB	
        Safari	        879,6 MB     10,0 MB	
        mds_stores          726,2 MB    570,1 MB		
        systemstatsd        695,0 MB    775,0 MB
        nsurlstorag         685,3 MB      9,5 MB	
        Google Chrom        681,4 MB    303,5 MB		
        iTerm2	        653,7 MB      1,6 GB	
        cfprefsd	        509,1 MB     45,8 MB	
        Papers 3.4.7        465,9 MB    169,8 MB
        cloudd	        441,3 MB      9,7 MB
        ruby	        224,6 MB      1,7 MB	
        coreduetd	        217,5 MB		
        Reeder	        207,2 MB     28,5 MB 
        apsd	         65,7 MB     11	MB    
        Safari	         55,3 MB     12,6 MB	
    

I've long gotten used to "bird" doing it's thing (something with the cloud I
guess). But how can a twitter client write 3GB (while I'm not even actually
using it?)

~~~
bartvk
You can check out what bird does. This Python script showed me that the
Whatsapp desktop app was consuming a couple of gig:
[https://github.com/bwesterb/blame-bird/blob/master/blame-
bir...](https://github.com/bwesterb/blame-bird/blob/master/blame-bird.py)

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

I hope we can get around to doing it someday. Of course, as usual in an open-
source project, contributors welcome :)

~~~
fulafel
How about this: 29 out of 30 times, save only a diff to the previous data. 1
out of 30 times, save the complete data in compressed form.

(I'm guessing there must already be functionality to diff a bunch of JSON
somewhere in the millions of lines of code).

Though I'm sure this doesn't make usually make a dent in a SSD's lifetime. But
there are still people running Firefox on low end Android phones with meager
flash, and Raspberry Pis with SD cards.

~~~
Yoric
> How about this: 29 out of 30 times, save only a diff to the previous data. 1
> out of 30 times, save the complete data in compressed form. > > (I'm
> guessing there must already be functionality to diff a bunch of JSON
> somewhere in the millions of lines of code).

That is actually a good idea we haven't considered yet. A bit too brute force
for my tastes, but relatively easy to implement. We would need to determine
how much CPU is needed for a diff between two 300Mb JSON files, though (yes,
some users have these).

Of course, we're back to the issue of manpower, but definitely worth trying
out.

> Though I'm sure this doesn't make usually make a dent in a SSD's lifetime.
> But there are still people running Firefox on low end Android phones with
> meager flash, and Raspberry Pis with SD cards.

The implementation of Session Restore for Android is largely independent, so
I'm not sure how it works these days.

~~~
acqq
Why is there so much data in the session restore anyway? If the goal is to
have the URLs of the currently opened tabs, I'd expect that just the given
URLs should be enough? I think I've seen some unexpected stuff there like the
images base64 encoded? Maybe there's enough users that would be satisfied just
with the URLs? At least for them the "rewrite" would be seldom needed.

Or, maybe to reformulate, which wild scenarios does Firefox want to support
now? I can imagine that the user's experience wouldn't match the wishes. Some
people that use session restore claimed they "lost everything" from time to
time, and I had to fish "just the urls" from their session store files which
looked strange ("full of everything"), but automatically restored to nothing.

~~~
holygoat
Session store contains open tabs, windows, history for each tab, form fields,
referrers (so we can re-request the page correctly), titles (so we can restore
tabs without re-fetching every page), favicons, charsets, some timestamps,
extension data, some kinds of site storage, scroll positions, and a few other
things.

The goal of session restore is to restore your session -- your open tabs
should come back, the same pages should load, scrolled to the same place, and
with the right content.

~~~
Ankaios
I'd wish they'd also restore themselves to the proper location on the proper
virtual desktop. With hundreds of windows, typically organized by task, I
dread having to reorganize things every time Firefox (or the computer)
restarts.

Someday the pain may motivate me to try to learn enough about Firefox's
internals to do it. :)

~~~
stuaxo
Definitely worth filing a bug in bugzilla if they are not on the right virtual
desktop... it might take years to get fixed, but they do generally get round
to it.

~~~
glandium
There already is a 10 years old bug about the issue:
[https://bugzilla.mozilla.org/show_bug.cgi?id=372650](https://bugzilla.mozilla.org/show_bug.cgi?id=372650)

------
zbuf
I have been running Firefox for a long time with an LD_PRELOAD wrapper which
turns fsync() and sync() into a no-op.

I feel it's little antisocial for regular desktop apps to assume it's for them
to do this.

Chrome is also a culprit, a similar sync'ing caused us problems at my
employer's, inflated pressure on an NFS server where /home directories are
network mounts. Even where we already put the cache to a local disk.

At the bottom of these sorts of cases I have on more than one occasion found
an SQLite database. I can see its benefit as a file format, but I don't think
we need full database-like synchronisation on things like cookie updates; I
would prefer to lose a few seconds (or minutes) of cookie updates on power
loss than over-inflate the I/O requirements.

~~~
robbles
Would you be willing to post a how-to or example of doing this? I'm curious
about how this trick works!

~~~
necessity
It's probably best to just disable sessionstore if you don't want it, as
overwriting fsync would disable it for all operations Firefox might use, not
just sessionstore.

~~~
zbuf
That's exactly what I wanted to achieve; I didn't have the time or inclination
to work out exactly which part of Firefox is responsible.

In my case it was not SSD wear I wanted to reduce, but the short pauses during
interactive use.

------
RussianCow
Serious question: Is 12GB a day really going to make a dent in your SSD's
lifespan? I was under the impression that, with modern SSDs, you basically
didn't have to worry about this stuff.

~~~
gcp
Samsung's low cost line is under warranty up to 40TB/year. Tests have shown
that the actual drive lifetime is several times that.

So basically, no, you don't have to worry about this. Essentially, people are
complaining that the disks they bought are being used for their intended
purpose: making sure your data doesn't disappear on a power loss.

~~~
dogma1138
Not everyone buys Samsung, there are a lot of cheap SSD's out there that are
rated for only a handful of TB's a year.

There is also a case of the silly SSHD's or w/e which combine a tiny SSD and a
mechanical component which can die considerably faster.

Overall the amount of writes an SSD can handle is tied directly to it's
capacity since it determines the amount of average writes per a given time
unit that each cell will experience as long as the firmware actually does it's
job (in Samsung's case it may very well not do it as they had more than a few
firmware screw ups in the past).

This can also more severely affect you if you have a medium sized drive (say
128-256GB) but it's pretty full.

A good SSD's will move things around somewhat to even out the wear but it
still increases the amount of writes you have.

If your SSD does have an "even wear" feature when you write 12GB to drive
which is say 50% or more full it usually triggers more than 12GB of effective
writes in the drive itself as the firmware would move already written data
around to ensure that every cell has been written to approximately the same
amount (if you say only have 20GB of free space and you write 12GB daily and
delete it, your effective writes would be closer to the full capacity of the
drive per day than to 12GB).

You also have a lot of embedded/mobile devices which use considerably shittier
storage than modern SSD's, you can easily chew through a SD card or a
similarly rated flash storage with anywhere between a few 100's of gigs to
only a handful of TB's (or a only few times the capacity of the card if buy
bargain bin memory cards).

Since these machines are more commonly used these days it's not a feature that
should be so quickly obfuscated from the user since it doesn't seem like there
is an "intelligence" behind how conservative or not the browser is with writes
to local storage.

If you install firefox on an SBC/netbook/microcomputer or even a mobile phone
(if this affects the mobile version also) with eMMC/MMC only rated storage 12
gigs a day can and will kill it rather quickly.

~~~
dsr_
Android Firefox has this set to 10 seconds, rather than the 15 on a desktop.

~~~
necessity
I think there's something wrong with OP's Firefox. Looking at IO_WBYTES in
htop I have exactly 42MB written after 2h11min of operation with 5+ tabs
opened at any given time. I have my sessionstore.interval set to 1min.
Assuming that if it ran 4x faster (default) it would write 4x more it should
be 168MB in 2h of operation, whereas OP reports 1GB every 2h.

~~~
RussianCow
5 tabs isn't very many. If the OP has 40+ tabs open at a time, following that
math, it should hit 1GB pretty easily.

------
rayiner
Doing all this work is also probably burning battery life. An SSD can use
several watts while writing, versus as low as 30-50 milliwatts at idle (with
proper power management).

~~~
dclowd9901
Can confirm closing chrome typically doubles my battery life.

------
blinkingled
Even better just disable session restore entirely -
Browser.sessionstore.enabled - Since Firefox 3.5 this preference is superseded
with setting browser.sessionstore.max_tabs_undo and
browser.sessionstore.max_windows_undo to 0.

As I understand this feature is there so if the browser crashes it can restore
your windows and tabs - I don't remember having a browser crash on me since
the demise of Flash.

~~~
raverbashing
Replace Browser Crash with: Accidentally pressing Ctrl-w

And yes, there are browser crashes without Flash

~~~
garaetjjte
Ctrl-W is not that bad, but I sometimes want to close tab by Ctrl-W but
instead hit Ctrl-Q...

~~~
sdkmvx
I've been setting browser.showQuitWarning to true for years to stop ^Q from
killing the browser and with it my state.

~~~
digi_owl
Could have sworn that has crap all effect if you also have Firefox save your
tabs on quit.

------
robin_reala
It’s always annoying when an issue like this is reported yet no bugzilla
reports are mentioned. Has anyone else filed this already, or shall I?

~~~
gcp
[https://bugzilla.mozilla.org/show_bug.cgi?id=1304389](https://bugzilla.mozilla.org/show_bug.cgi?id=1304389)

------
Someone
12GB/day is about 140kB/second, or one Apple 2 floppy disk every second.

It also is about single CD speed (yes, you could almost record uncompressed
stereo CD quality audio all day round for that amount of data)

All to give you back your session if your web browser crashes or is crashed.

Moore's law at its best.

------
vesinisa
I've already moved all my browser profiles to `/tmp` and set up a bootscripts
to persist them during boot / shutdown. E.g. for Arch Linux see
[https://wiki.archlinux.org/index.php/profile-sync-
daemon](https://wiki.archlinux.org/index.php/profile-sync-daemon)

This is a far superior solution to fiddling with configuration options in each
individual product to avoid wearing down your SSD with constant writes.
Murphy's law has it such hacks will only be frustrated by next version
upgrade.

And no, using Chrome does not help. All browsers that use disk caching or
complex state on disk are fundamentally heavy on writes to an SSD. The amount
of traffic itself is not even a particularly good measure of SSD wear, since
writing a single kilobyte of data on an SSD can not be achieved on HW level
without rewriting the whole page, which is generally several megabytes in
size. So changing a single byte in a file is no less taxing than a huge 4 MB
write.

------
raverbashing
Are these writes being sync'd to disk?

Because FF may die but the OS will save it later. That's fine

Not every write to a file means a write to disk

~~~
holygoat
sessionstore does not fsync.

------
CoryG89
Maybe I am not understanding this right, but is this saying that Firefox will
continually keep writing to the disk while idle? Does anyone know more about
this? Why would this be needed to restore session/tabs? Seems like it should
only write after a user action or if the open page writes to storage? Even if
it was necessary to write continually while idle, how could it possibly
consume so much data in such a short period of time?

~~~
gcp
_Maybe I am not understanding this right, but is this saying that Firefox will
continually keep writing to the disk while idle? Does anyone know more about
this? Why would this be needed to restore session /tabs?_

This is very much the feature working as intended: Firefox captures webpage
state every 15 seconds, so a crash, power outage, accidentally closing the
browser etc will not result in data loss for the user. For storing the data
persistently, it uses the persistent storage, i.e. your harddrive. For the HN
crowd, that's going to be an SSD. The SSD can easily deal with the resulting
write traffic with negligible effect on its lifetime - I have no idea why
people even think this is an issue.

 _Seems like it should only write after a user action or if the open page
writes to storage_

Webpages can change their contents or state without user interaction.

Webpages are also big and bloated. Storing a little data, all the time, 24/7,
adds up over time to a surprisingly large number.

~~~
CoryG89
I understand that pages can change their state without user interaction, but
shouldn't the browser only write to disk when that actually happens? The
browser has to be able to detect when these changes happen right?

I understand that it's probably not an issue for most users/SSDs. However, if
I open just a static HTML file and leave it idle, I don't think the browser
should be continually writing to disk. If it is, then to me that is a bug.

EDIT: Also, it seems like when I remember restoring a browser session after a
crash, all the tabs get reloaded, not restoring the page state, just the
tabs/URLs (ie. browser makes new request(s) for each restored tab). I usually
use Chrome though, not sure if this has happened to me on Firefox.

~~~
gcp
It won't write to disk with static pages. But most of the web doesn't fit that
description, and you're bound to have a tab open that does something in the
background.

Yoric pointed out here that not being able to save tabs individually is a weak
point of the current implementation.

------
weatherlight
Spotify does some pretty evil I/O as well.
[https://community.spotify.com/t5/Desktop-Linux-Windows-
Web-P...](https://community.spotify.com/t5/Desktop-Linux-Windows-Web-
Player/Why-does-Spotify-use-such-a-ridiculous-amount-of-disk-I-O-
Writes/td-p/1130146)

------
towerbabbel
I observed something similar several years ago:
[http://www.overclockers.com/forums/showthread.php/697061-Whe...](http://www.overclockers.com/forums/showthread.php/697061-Where-
those-writes-to-the-SSD-comes-from)

I still think the worry about it wearing out an SSD is overblown. The 20GB per
day of writes is extremely conservative and mostly there to avoid more
pathological use cases. Like taking a consumer SSD and using it as the drive
for some write heavy database load with 10x+ write amplification and when you
wear it out demand a new one on warranty.

Backing up the session is still sequential writes so write amplification is
minimal. After discovering the issue I did nothing and just left Firefox there
wearing on my SSD. I'll still die of old age before Firefox can wear it out.

------
alyandon
Yep, I have a brand new SSD drive that over the course of a few months
accumulated several TERAbytes (yes - TERA) of writes directly attributable to
the default FF browser session sync interval coupled with the fact I leave it
open 24/7 with tons of open tabs.

Once I noticed that excessive writes were occurring, it was easy for me to
identify FF as the culprit in Process Hacker but it took much longer to figure
out _why_ FF was doing it.

------
zx2c4
I have fixed this issue forever. I got a Thinkpad P50 with 64 gigs of ram. So,
I just mount a tmpfs over ~/.cache.

I actually use a tmpfs for a few things:

    
    
        $ grep tmpfs /etc/fstab
        tmpfs	/tmp			tmpfs	nodev,nosuid,mode=1777,noatime	0 0
        tmpfs	/var/tmp/portage	tmpfs	noatime	0 0
        tmpfs	/home/zx2c4/.cache	tmpfs	noatime,nosuid,nodev,uid=1000,gid=1000,mode=0755	0 0

~~~
Yoric
Fwiw, Session Restore doesn't hit ~/.cache at all. (Afaict, I'm the last
person who changed how Session Restore writes its files).

------
Falkon1313
I checked my system - Firefox wasn't writing much and what it is writing is
going to my user directory on the hard drive instead of the program directory
on the SSD, so that's nice. But still, I don't want my browser cluttering up
my drive with unnecessary junk - history, persistent caching from previous
sessions, old tracking cookies, nevermind a constant backup of the state of
everything. I try to turn all that off, but there's always one more hidden
thing like this.

If I want to save something, I'll download it. If I want to come back, I'll
bookmark it. Other than those two cases and settings changes, all of which are
triggered by my explicit choice & action, it really shouldn't be
writing/saving/storing anything. Would be nice if there were a
lightweight/portable/'clean' option or version.

When I tried Spotify, it was pretty bad about that too - created many
gigabytes of junk in the background and never cleaned up after itself. I made
a scheduled task to delete it all daily, but eventually just stopped using
spotify.

~~~
db48x
It's overwriting a few files when the data they contain changes; it's not
leaving a huge pile of unused data to clutter up your disk.

------
tsukikage
The interesting question here is, why is the browser writing data to disk at
this rate?

If it's genuinely receiving new data at this rate, that's kind of concerning
for those of us on capped/metered mobile connections. The original article
mentions that cookies accounted for the bulk of the writes, which is
distressing.

If it's not, using incremental deltas is surely a no-brainer here?

~~~
gcp
_If it 's not, using incremental deltas is surely a no-brainer here?_

Might be surprisingly hard or inefficient given that you're trying to capture
"webpage state". Think about React sites etc.

------
nashashmi
On a related note: also see [http://windows7themes.net/en-us/firefox-memory-
cache-ssd/](http://windows7themes.net/en-us/firefox-memory-cache-ssd/)

Just another firefox ssd optimization.

Edit: And see bernaerts.dyndns.org/linux/74-ubuntu/212-ubuntu-firefox-tweaks-
ssd

It talks about sessionstore.

------
justinrstout
Theodore Ts'o wrote about a similar Firefox issue back in 2009:
[https://thunk.org/tytso/blog/2009/03/15/dont-fear-the-
fsync/](https://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/)

------
leeoniya
i'm not seeing these numbers, using I/O columns in Process Explorer. i'm
running Nightly Portable with maybe 80 tabs open/restored.

~~~
gcp
Nightly Portable might have this particular setting changed, because the
lifetime of random USB sticks is surely going to be much less than a real SSD.

~~~
leeoniya
i thought that too but the interval setting is at 15000 in the config, so
maybe something else is optimizing it out?

------
known
[https://wiki.archlinux.org/index.php/Firefox_tweaks](https://wiki.archlinux.org/index.php/Firefox_tweaks)
is worth skimming

------
joosters
Does firefox sync() the data? If not, these continuous overwrites of the same
file may not even hit the disk at all, as it could all end up being cached.

Even if some data is being written, it could still be orders of magnitude
lower than the writes executed by the program.

There are legitimate pros/cons of using sync() or not. Missing it out could
mean that the file data is lost if your computer crashes. But if firefox
crashes by itself, the data will be safe.

~~~
cwillu
fsync() is a very different thing from sync(), and it's the former that is
relevant here. ext3 configured in a manner that used to be popular had a side
effect of making fsync() require nearly as much io as sync, which is probably
where the confusion comes from.

------
vamur
Using private mode and a RAM disk is a quick solution for this issue. Easy to
setup on Linux and there is a free RAM disk utility on Windows as well.

------
Nursie
Firefox has been terrible for disk access for many years. I remember I had a
post install script (to follow, I never actually automated) that I would run
through in my linux boxes back in about 2003 that would cut down on this and
speed up the whole system.

Basically chattr +i on a whole bunch of its files and databases, and
everything's fine again...

~~~
gcp
There's been some development the last 13 years.

Chrome was also pretty crappy in 2003. /s

~~~
Klathmon
well, i'd say it was crappy in 2003, it wouldn't even exist for another 5
years ;)

------
digi_owl
I do wonder if their mobile version have a similar problem. I have noticed it
chugs badly when opened for the first time in a while on Android, meaning i
have to leave it sitting or a while so it can get things done before i can
actually browse anything.

~~~
darkhorn
I've disabled images and JavaScript on mobile Firefox. When I'm only
interested on reading I use Firefox. Otherwise I use Google Chrome.

~~~
digi_owl
Thats the thing, it has nothing to do with page rendering.

It kicks in about 10-15 seconds after initial launch of the browser, and
basically churns it to a near halt for at least 30 seconds before it becomes
usable.

Could be that this tablet of mine provokes the behavior by having a slow emmc
that is nearly full, but it has resulted in me minimizing my use of a browser
i have been using for close to a decade across various computers and operating
systems.

And no, it has nothing to do with extensions. I still see it with no
extensions active. Heck, i even see it with guest mode active.

~~~
holygoat
Do you have Sync enabled?

If you can grab an adb log, come post it in #mobile on irc.mozilla.org.

~~~
digi_owl
Yep, i have sync enabled.

Grabbing a adb log may be a bit out of my league though.

------
iask
So Firefox is also expensive to run in terms of energy consumption. No wonder
the fans on my MacBook Pro always sound like a jet engine whenever I have
several tabs open. Seriously!

Disclaimer: I dual boot (camp) windows 7 on my mac.

~~~
cwillu
I doubt the cpu load of session restore is responsible for the fans kicking
in...

~~~
iask
Well I must say, I certainly changed my settings to 45 minutes and OMG! fans
haven't spin up loudly since. Wow!

------
waldbeere
Simple solution change save time to 30s

Windows file compression cookies.sqlite => 1MB => 472KB sessionstore-backups
=> 421 KB => 204 KB

Move TMP cach folder to ram drive ie ImDisk

------
tesla23
I'am sorry if I drop it, but it seems not many people know about cache
poisoning. I have always kept the suggested settings since the age of
javascript.

------
rsync
I continue to be impressed with the content and community at servethehome -
it's slowly migrated its way into my daily browsing list.

------
Animats
Firefox is relying too much on session restore to deal with bugs in their
code. Firefox needs to crash less. With all the effort going into multiprocess
Firefox, Rust, and Servo, it should be possible to have one page abort without
taking down the whole browser. About half the time, session restore can't
restore the page that crashed Firefox anyway.

~~~
Manishearth
IIRC per-tab e10s already exists, just isn't enabled by default yet because it
has some rough edges.

The Rust part of your comment is irrelevant. There is Rust code shipping in
Firefox, but nowhere near the amount needed for observable changes in
behavior. Work is being done to put larger components in but nothing is
shipping yet. Also, IME most crashes are asserts (in all browsers) and that's
not a problem Rust fixes. If you get a segfault-based crash please report it,
it could be exploitable. (report normal crashes too, really)

~~~
Animats
If process-per-tab is enabled, can each tab crash separately, or does the
whole browser still have to go down?

~~~
Manishearth
It seems like the dom.ipc.processCount setting sets the total number of
content processes to use.

Note that this means that tabs will share content processes, so a crash in one
tab may crash a few others. You can reduce this by ramping up the number of
processes, though that can lead to bloat.

No idea how stable this is right now. For me, on Dev Edition with regular
multiprocess mode enabled, things work fine and I don't get crashes.

------
Freestyler_3
I use Opera on windows, No idea how to check or change the session storage
interval.

Anyone got ideas on that?

------
HorizonXP
Wow, that's really unfortunate.

I just built a new PC with SSDs, and switched back to Firefox. Even with 16GB
of RAM on an i3-2120, Firefox still hiccups and lags when I open new tabs or
try to scroll.

This new issue of it prematurely wearing out my SSDs will just push me to
Chrome. Hopefully it doesn't have the same issues.

~~~
__jal
My home desktop is an i5-1620 with 64G RAM running Ubuntu 16.04, and Firefox
just hiccups and lags, period. It is sad.

I need to find time to experiment with Chrome while blocking all the Google
chatter to see how functional it remains without being able to tattle to the
mothership (otherwise I won't use it).

~~~
brianwawok
Why not Chromium?

~~~
CaptSpify
I personally wouldn't recommend chromium because they've been known to do some
shady things: [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=786909](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=786909)

I'd imagine someone like the above poster would be concerned about that. At
least I know I am

------
Sami_Lehtinen
uBlock also keeps writing "hit counts" to disk all the time, as well as for
some strange reason they've chose database page size to be 32k so each update
writes at least 32kB.

~~~
gcp
Smaller block sizes caused large performance issues. SQLite isn't very good at
keeping its data unfragmented, and not everyone has SSDs.

------
yashafromrussia
Sounds sweet, ill try it out. How is it comparing to ack (ack-grep)?

------
dogma1138
heh
[https://news.ycombinator.com/item?id=12437309](https://news.ycombinator.com/item?id=12437309)

------
bikamonki
Can this be avoided in FF and Chrome with private tabs?

------
falsedan
Using a display font for body text--

------
aylons
In Linux where should this be written? Inside the home folder?

Maybe moving this folder to a HDD should suffice.

~~~
gcp
Why would you not want to use your SSD for what it's meant for?

~~~
aylons
Some things are in the SSD, others on the HDD. This seems to wear the SSD
while being seldomly used. Looks like a good case for HDD.

------
caiob
That goes to show how space/memory hungry and bloated browsers have become.

------
gcb0
> goes to the point of installing weird programs to be "pro" about their ssd
> life

> failed to read the very first recommendation on every single guide for ssd
> life: use ram disk cache for browser temp files.

yeah, let's upvote this

------
rasz_pl
For comparison ancient Opera Presto stores about 500 bytes per tab in Session
file.

------
amq
Observed similar behavior with Skype.

------
PaulHoule
The whole "restore your session" thing is the one of the most user hostile
behaviors there is.

------
rackforms
Putting aside how this may not be all that bad for most SSD's, does anyone
know when this behavior started?

Firefox really started to annoy me with its constant and needless updates a
few months back; the tipping point being breaking almost all legacy extensions
(in 46, I believe). This totally broke the Zend Debugger extension, the only
way forward would be to totally change my development environment. I'm 38 and
now, and apparently well beyond the days when the "new and shiny" hold value.
These days I just want stability and reliability.

Firefox keeps charging forward and, as far as I can tell, has brought nothing
to the table except new security issues and breaking that which once worked.

I haven't updated since 41 and you know what, it's nearly perfect. It's fast,
does what I need it to do, and just plain old works.

Firefox appears to have become a perfect example of developing for the sake
of.

~~~
gcp
Much of the recent breakage was to introduce essential features that users
have been loudly asking for for years, such as multi-process support and
content processes in a security sandbox.

If you're intentionally running very old versions which by now have published
exploits, then I can see that these are not things you would consider
important.

~~~
rackforms
Progress at what cost? Does maintaining security have to also mean breaking
the systems that pay my bills?

~~~
gcp
I do not think you want to be paying your bills on a browser that's been
compromised, no.

~~~
rackforms
It's a dev box that only touches local resources.

------
kordless
I seriously dislike Firefox, but must use it at work due to browser
incompatibility issues with Chrome and sites I use heavily. Anything that
makes the experience better is much appreciated.

~~~
tonmoy
If is perfectly valid for you to dislike Firefox. But in the context of this
post it seems that you assume Chrome is better than FF in terms of disc usage.
Do you have any data to back that claim up?

