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

221–230 of 361 posts

Re: Heavy SSD Writes from Firefox

#221

Post by sandGorgon »

weaksauce wrote: post #146
sandGorgon wrote: post #128

Earlier quoted context omitted.

this is brilliant. P.S. your chrome link is broken. On suggestion - please give a button to save all of this as a "session" or something. I'm a tab hoarder and sometimes I just want to dump it somewhere and start afresh. Please help me !

Thanks! the link is fixed now... I actually did just this thing the other day but didn't know if other people would want it. I will update the addon with it.

if you could do one more thing - allow me to search within the "sessions". that would be awesome (search should work both on domain and title)

thanks!

Re: Heavy SSD Writes from Firefox

#222

Post by Yoric »

reitzensteinm wrote: post #185
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…

Surely you'd diff the data structures in memory, not the serialized JSON; and would it really be faster to blindly write the 300mb each time than perform this diff?

To be benchmarked.

Re: Heavy SSD Writes from Firefox

#223

Post by Yoric »

bsdetector wrote: post #194
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…

You could at least just compress the data with LZF or any of the really fast text compressors. It'll compress to about 30% of the size, it's easy to do, and it shouldn't add more than a tiny CPU overhead over formatting the JSON itself. It solves half the problem with like 15 minutes of work.

Actually, we had a prototype doing this. In the end, we didn't because it broke some add-ons, but it might be time to try again.

Re: Heavy SSD Writes from Firefox

#224

Post by Yoric »

Dylan16807 wrote: post #191
Yoric wrote: post #156

Earlier quoted context omitted.

I haven't worked on Session Restore in some time. But from the top of my head, it would be as follows. On the back-end, I believe that Session Restore should be backed by a database, with each tab updated independently, rather than a big bunch of JSON data. The rationale being that: - it's performance-critical; - it's safety-critical; - we have users with 300+ Mb of data in their Session Restore and JSON isn't meant…

How does that much data get into Session Restore? Mine are only about 3KB per tab, and Firefox starts melting at more than a thousand tabs.

I seem to remember that DOM Session Storage and Session Cookies are pretty big offenders. Other websites (e.g. Google Docs) use lots and lots and lots of hidden forms to remember lots and lots and lots of data.

Also, people who keep Session Restore tabs open (you know, the tab that lets you restore your session, when you have crashed) and continue browsing – Firefox needs to store several nested Session Restore JSON files.

Re: Heavy SSD Writes from Firefox

#225

Post by schiffern »

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.

The problem isn't that data is being written (that's desirable, in fact). The problem imo is that data is being written unnecessarily.

Firstly it shouldn't be backing up every "N" seconds. It should be backing up after every change, and for performance reasons coalescing changes in time interval bins (eg 1-5 second blocks).

Secondly, it should only be writing the information that changes. Sure websites contain a lot of data, but most of it doesn't change very fast. So it's a big win to only back up the deltas (and reconstructing it is fast on SSDs).

If a page does have lots of transient data... write lots of data! That's partly how the time coalescing parameter is tuned.

Ideally it would only write out the entire page of data when it loads, or when the size of the deltas exceeds some threshold (possibly different for HDD vs SSD).

Re: Heavy SSD Writes from Firefox

#226

Post by tracker1 »

pixl97 wrote: post #111
gcp wrote: post #102

Earlier quoted context omitted.

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.

You apparently haven't seen some of the SPAs that are in use out there... I can very validly consider an issue with losing even a minute vs 15 seconds being considered in favor of the latter.

It might be nice if this was tunable via a setting though.

Re: Heavy SSD Writes from Firefox

#227

Post by ciupicri »

rayiner wrote: post #30
RussianCow wrote: post #4

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.

Some cheap drives (e.g. Crucial BX100) have an endurance rating of only about 40GB/day.

The 56GB and 120GB version of the Intel 535 SSD have even less, just 20GB of host writes per day [1].

[1]: http://www.intel.com/content/dam/www/public/us/en/documents/... section 2.6

Re: Heavy SSD Writes from Firefox

#228

Post by acqq »

Yoric wrote: post #142
fulafel wrote: post #134

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). 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, a…

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

Re: Heavy SSD Writes from Firefox

#229

Post by tracker1 »

sangnoir wrote: post #135
gcp wrote: post #93

Earlier quoted context omitted.

I dunno but I think plenty of people consider their web browser a pretty vital application.

> I dunno but I think plenty of people consider their web browser a pretty vital application. No one is arguing against that point. However, most people do not need their browser state to be needlessly backed-up that aggressively (every 15 seconds - which is about the same time it took me to type everything before this sentence). I'm OK with losing up to 20 minutes of my state in a browser. Most work done in a browse…

And when you just spent 10 minutes finding the link you need, and your browser crashes, you're going to spend a lot more time again. There are plenty of cases where I'm really glad my browser re-opens all the tabs, with cookies in play etc.

If your job includes having to use a web application for significant portions of said job, it's even more invaluable. I've worked on several applications that account for more than 40% of some employees' time per day... This was back in the IE6 days, they bemoaned having to close/reopen once a day because of memory issues (IE6 had horrible GC across COM boundaries).

Re: Heavy SSD Writes from Firefox

#230

Post by tracker1 »

Phlarp wrote: post #27
RussianCow wrote: post #4

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.

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