Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heavy SSD Writes from Firefox

servethehome.com

Post reply on HN
Print view View original

111–120 of 361 posts

Re: Heavy SSD Writes from Firefox

#111

Post by pixl97 »

gcp wrote: post #102
nathanaldensr wrote: post #97

Earlier quoted context omitted.

No, "people" are not complaining about that; it's a fine attempt at a straw man, though. What the article complains about through implication is that Firefox is unnecessarily writing too much data to disk.

Why would it be unnecessary? The amount of data follows rather logically from the amount of website state it's capturing, and the interval seems totally like personal preference to me. Would you rather lose 60 seconds of work or 15? Uh, I'll take less data loss.

In a web browser?

You're acting like the browser is a major local storage application (like excel for example), almost everything I'm going to be working on is an online application, and it takes care of storing my data on the server infrastructure. So yea, 15 seconds or 60 seconds isn't going to be a major 'data loss' issue either way.

Re: Heavy SSD Writes from Firefox

#113

Post by m_rcin »

lighttower wrote: post #8

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…

Arch Wiki describes how to do it manually: https://wiki.archlinux.org/index.php/Firefox_on_RAM

Re: Heavy SSD Writes from Firefox

#114

Post by necessity »

robbles wrote: post #109
zbuf wrote: post #67

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

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

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.

Re: Heavy SSD Writes from Firefox

#115

Post by dogma1138 »

gcp wrote: post #102
nathanaldensr wrote: post #97

Earlier quoted context omitted.

No, "people" are not complaining about that; it's a fine attempt at a straw man, though. What the article complains about through implication is that Firefox is unnecessarily writing too much data to disk.

Why would it be unnecessary? The amount of data follows rather logically from the amount of website state it's capturing, and the interval seems totally like personal preference to me. Would you rather lose 60 seconds of work or 15? Uh, I'll take less data loss.

what information would you lose exactly?

Re: Heavy SSD Writes from Firefox

#116

Post by CoryG89 »

gcp wrote: post #86
CoryG89 wrote: post #42

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

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…

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.

Re: Heavy SSD Writes from Firefox

#117

Post by rackforms »

gcp wrote: post #94
rackforms wrote: post #87

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

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.

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

Re: Heavy SSD Writes from Firefox

#118

Post by superkuh »

HorizonXP wrote: post #2

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.

Try out the Pale Moon firefox forks. I'm running it on an old core2duo 6400 (2.13 GHz) with 8 GB ram. I have over 700 tabs in my session right now with at least 300 of them fully loaded. It's using less than 3GB ram. And it's fast/snappy with smooth scrolling.

Re: Heavy SSD Writes from Firefox

#119

Post by sandGorgon »

lighttower wrote: post #8

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…

this is the first I heard of this - why is this not a config flag ?

Re: Heavy SSD Writes from Firefox

#120

Post by toxican »

lucb1e wrote: post #84
lighttower wrote: post #8

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…

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 For Debian and co: $ apt-cache show profile-sync-daemon $ sudo apt-get install profil…

As someone who took the plunge into Debian from Ubuntu yesterday, thank you!
Post reply on HN