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

251–260 of 361 posts

Re: Heavy SSD Writes from Firefox

#251

Post by holygoat »

acqq wrote: post #228
Yoric wrote: post #142

Earlier quoted context omitted.

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

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 pages should load, scrolled to the same place, and with the right content.

Re: Heavy SSD Writes from Firefox

#252

Post by holygoat »

asimuvPR wrote: post #188
Yoric wrote: 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…

Long time Netscape/ firefox user here: 1. Thanks for your work. 2. How do I really contribute? Could you link to what I need to do to start working on this now ? I'm affected by this problem ame want to figure out if I can fix it.

http://whatcanidoformozilla.org is a good starting point.

Re: Heavy SSD Writes from Firefox

#253

Post by dewiz »

Yoric wrote: post #171
chmike wrote: post #154

Earlier quoted context omitted.

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.

As an heavy user of session restore and tons of open tabs, I would be OK ignoring updates to tabs that have not been active for a while.

For example, let's say I have 10 tabs open but I have been using only the latest tab during the last 5 minutes. In this scenario I don't care about the cookies (eg due to ongoing ajax) nor the state of the other 9 tabs. If the browser crashes I'm OK with those 9 tabs being restored with a 5 minutes old snapshot.

So for instance FF should be smart to save the state of new/recent tabs, and should slow down progressively on old/inactive tabs.

Re: Heavy SSD Writes from Firefox

#254

Post by waterhouse »

wolf550e wrote: post #248
avar wrote: post #235

Earlier quoted context omitted.

Only if the sync is the equivalent of: rsync [...] /dev/shm/.browser ~/.browser Instead of: rsync [...] /dev/shm/.browser ~/.browser.new && ln -sf ~/.browser.new ~/browser Or some such equivalent, i.e. doing the full sync and then atomically juggling a symlink around.

that creates many more writes to the ssd.

Does it? Consider this scheme: maintain two physical directories, one of which is current (and is named by a symlink) and the other of which is old. When doing a sync, you rsync the newest data into the old directory, then update the symlink. It'll probably result in somewhere between 1x and 2x the writes as the non-atomic single-directory scheme, depending on how well adjacent diffs combine. It will also result in twice the space used (barring some very clever filesystem).

Re: Heavy SSD Writes from Firefox

#255

Post by digi_owl »

darkhorn wrote: post #246
digi_owl wrote: post #199

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.

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

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.

Re: Heavy SSD Writes from Firefox

#256

Post by Ankaios »

holygoat wrote: post #251
acqq wrote: 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…

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

Re: Heavy SSD Writes from Firefox

#257

Post by sitkack »

derefr wrote: post #241
spullara wrote: post #201

Earlier quoted context omitted.

if it happens during the sync you could be arbitrirly broken.

This isn't really the sync daemon's fault; it's Linux's (or rather, ext4's, and the Linux VFS ABI's) for not supporting multi-inode filesystem transactions. NTFS has them; APFS will have them. Linux should add them too.

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

Re: Heavy SSD Writes from Firefox

#259

Post by holygoat »

joosters wrote: post #233

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…

sessionstore does not sync.

Re: Heavy SSD Writes from Firefox

#260

Post by holygoat »

digi_owl wrote: post #255
darkhorn wrote: post #246

Earlier quoted context omitted.

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

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…

Do you have Sync enabled?

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

Post reply on HN