Live data from Hacker News

Heavy SSD Writes from Firefox

servethehome.com

171–180 of 361 posts

Re: Heavy SSD Writes from Firefox

#171
post #154
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…

Why writing to disk if firefox is idle and its state doesn't change ? Is it repeatedly rewriting the same data over and over in a storage working like a log database or journal file ?

Unless there is a bug, Session Restore is not written if Firefox is idle. Of course, many applications are not idle even if you're not using them, and with the current architecture, just one tab using, say, DOM Storage, or updating a session cookie or a hidden form field, is enough to force a rewrite.

Re: Heavy SSD Writes from Firefox

#172
post #91
post #82

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

There's been some development the last 13 years. Chrome was also pretty crappy in 2003. /s

Oh there's been lots. Looks like it's still incredibly write-happy though.

Re: Heavy SSD Writes from Firefox

#173
post #11

Earlier quoted context omitted.

Other things than a browser crash can cause the browser to unexpectedly quit. For example, a battery dying, or the power going out.

Right but that doesn't happen quite often either. Also if it does how important is restoring the tabs and windows? Probably not to a lot of people other than serious creators that use a web editor of some sort that'll lose work if the browser disappears. Even then it is flaky to rely on something like this. Much better to have periodic backups of whatever you're doing.

You say "doesn't happen quite often", which I'm assuming means something like "doesn't happen quite often to me". But if you consider hundreds of millions of users using Firefox every day, then even a relatively rare event is happening to multiple users every single day. It is absolutely worth it to them that Firefox does its best to preserve their data.

Re: Heavy SSD Writes from Firefox

#174
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…

Why not leave the existing code (SR1) as is and rebuild Session Restore 2 (SR2); keep using SR1 until it has nothing to restore and then use SR2 moving forward.

That sounds pretty hard to pull off. What's the expected benefit?

Re: Heavy SSD Writes from Firefox

#175
post #139
post #132

Earlier quoted context omitted.

> Session Restore is rather safety-critical for many users Maybe you could give users the option? (until it can be fixed fully)

That's what the interval config setting is for?

I think brador is referring to the options page.

about:config shows a big warning message "This may void your warranty".

Re: Heavy SSD Writes from Firefox

#176

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 ?

Probably because most people don't want their profile to be broken if their OS crashes or their computer powers off unexpectedly?

Re: Heavy SSD Writes from Firefox

#178

Earlier quoted context omitted.

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

Probably because most people don't want their profile to be broken if their OS crashes or their computer powers off unexpectedly?

If you miss a sync, your profile isn't going to be 'broken', just out of date.

Re: Heavy SSD Writes from Firefox

#179
post #106
post #81

Earlier quoted context omitted.

And what if the server sends something different back when you visit the URL again? The internet allows it to do that.

The job of a browser is to view the internet. Not to cache it.

Go disable your browser cache and try browsing the internet for a while and tell me if you really believe that.

Re: Heavy SSD Writes from Firefox

#180
post #86

Earlier quoted context omitted.

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, t…

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.

Post reply on HN