Live data from Hacker News

Heavy SSD Writes from Firefox

servethehome.com

271–280 of 361 posts

Re: Heavy SSD Writes from Firefox

#271
post #26

In Linux where should this be written? Inside the home folder? Maybe moving this folder to a HDD should suffice.

Or ramdisk if you have a stable system.

That would lose the point of a recovery system. I'd rather just turn it off.

Re: Heavy SSD Writes from Firefox

#272
post #228

Earlier quoted context omitted.

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 scena…

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 pa…

Storing a lot of static images as JSON base64 encoded, every 15 seconds is certainly not something that users should be blamed ("some users have 300MB JSON files"), just the poor programming.

It would be interesting if somebody would actually analyze what takes the most of the mentioned 300 MB. I see a lot of base64 encoded stuff, if they are "favicons," come-on. There are so many caches in Firefox already, JSON files certainly aren't the place for these images.

Re: Heavy SSD Writes from Firefox

#273
post #74

Earlier quoted context omitted.

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

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

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

Re: Heavy SSD Writes from Firefox

#274
post #17

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

+1. This is why I use PSD (mentioned above) to mitigate this. A RAM cache will use much less power than constant disk writes.

Re: Heavy SSD Writes from Firefox

#275

Earlier quoted context omitted.

The sync daemon could sync with hardlink and then rename which is atomic.

That would require rewriting the entire directory.

hardlinks for the stuff not changed. Browsers of course, should move to append only file formats.

Re: Heavy SSD Writes from Firefox

#276

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…

Anything similar for macOS?

Re: Heavy SSD Writes from Firefox

#277
post #27

Earlier quoted context omitted.

Anecdote; I have had one of the OG intel x-25 80GB MLC SSD drives and after 5+ years of usage first as a boot drive and now as a video editing scratch disk the wear leveling firmware has done an excellent job. Intel's monitoring software still claims the disk has 95% of it's write capacity remaining and I have not observed any changes to it's benchmark IO performance over the life of the drive.

You're lucky... mine died after the original 1 year warranty (a few days over, it detected as 10MB drive or some such), I replaced it before they had a fix for the issue... that said, every drive I've had since has been very solid, mostly using Samsung drives these days.

The capacity error is fixable by using hdparm to secure erase the drive which as a side effect restores it’s original capacity.

You still lose all your data though :(

Re: Heavy SSD Writes from Firefox

#278
post #126

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 plent…

OTOH SSD lifetime is rather safety-critical for many users...

_Safety critical_? I doubt that...

Re: Heavy SSD Writes from Firefox

#279
post #27

Earlier quoted context omitted.

Anecdote; I have had one of the OG intel x-25 80GB MLC SSD drives and after 5+ years of usage first as a boot drive and now as a video editing scratch disk the wear leveling firmware has done an excellent job. Intel's monitoring software still claims the disk has 95% of it's write capacity remaining and I have not observed any changes to it's benchmark IO performance over the life of the drive.

You're lucky... mine died after the original 1 year warranty (a few days over, it detected as 10MB drive or some such), I replaced it before they had a fix for the issue... that said, every drive I've had since has been very solid, mostly using Samsung drives these days.

That has nothing to do with write endurance; it's a known bug in the firmware.

Re: Heavy SSD Writes from Firefox

#280

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 fire…

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.
Post reply on HN