> goes to the point of installing weird programs to be "pro" about their ssd life
> failed to read the very first recommendation on every single guide for ssd life: use ram disk cache for browser temp files.
yeah, let's upvote this
Heavy SSD Writes from Firefox
261–270 of 361 posts
Re: Heavy SSD Writes from Firefox
#262Earlier quoted context omitted.
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.
15 minutes of coding, perhaps. Then an hour of writing good tests. Then lots of manual and automated testing on four or five platforms, and fixing the weird issues you get on Windows XP SP2, or only on 64-bit Linux running in a VM, or whatever. Then making sure you don't regress startup performance (which you probably will unless you have a really, really slow disk). Then implementing rock solid migration so you can…
They already have Google's Brotli imported, they'd only need a small tweak to also include the encoder. Or use Snappy which is also in the codebase already.
Add the code that's able to load compressed session backups and leave it in for a couple versions.
Once enough versions have passed enable the code that writes compressed session backups.
It's really not that hard to do unless you want to enable it now.
Re: Heavy SSD Writes from Firefox
#263Chrome, 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 ?
because not losing data is infinitely better than saving your ssd life a couple years. we've had ssds for a long time now. still waiting for one to die on me. meanwhile I'm on my 27th dead spinning disk.
Re: Heavy SSD Writes from Firefox
#264Hi, 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…
link to bugzilla?
Re: Heavy SSD Writes from Firefox
#265Earlier quoted context omitted.
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.
15 minutes of coding, perhaps. Then an hour of writing good tests. Then lots of manual and automated testing on four or five platforms, and fixing the weird issues you get on Windows XP SP2, or only on 64-bit Linux running in a VM, or whatever. Then making sure you don't regress startup performance (which you probably will unless you have a really, really slow disk). Then implementing rock solid migration so you can…
> regress startup performance
No, for example, LZ4 is unbelievably fast:
https://github.com/Cyan4973/lz4
almost 2 GB per second in decompression!
I've just tried compressing some backupXX.session file (the biggest I've managed to find, just around 2 MB) and it compressed to 70% of the original, probably not enough to implement the compression -- and I suspect the reason is that the file contains too much base64 encode image files which can't be much compressed?
So the answer to having sane session files can be first to stop storing the favicons (and other images(?)) there? I still believe somebody should analyze the big files carefully to get the most relevant facts. For the start, somebody should make a tool that extracts all the pictures from the .session file (should be easy with python or Perl, for example), just that we know what's inside.
Re: Heavy SSD Writes from Firefox
#266Earlier quoted context omitted.
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.
Yep, i have sync enabled.
Grabbing a adb log may be a bit out of my league though.
Re: Heavy SSD Writes from Firefox
#267Earlier quoted context omitted.
this is the first I heard of this - why is this not a config flag ?
because not losing data is infinitely better than saving your ssd life a couple years. we've had ssds for a long time now. still waiting for one to die on me. meanwhile I'm on my 27th dead spinning disk.
Some people are unjustifiably worried about SSD endurance.
The reality is that even with fairly heavy use, most of them will far outlive the computers they're in. And their owners for that matter!
I purchased my current SSD in March 2015 - it's a Samsung 850 EVO 512GB. It's done 7332 Power_On_Hours, and 36486573259 Total_LBAs_Written, which works out as just under 17 TB written, or about 31.6 GB/day.
That kind of sounds like a lot. But let's put it in context. Even the previous generation of TLC NAND SSDs were recorded in endurance tests doing around 1 PETABYTE of writes before failing. The 850 EVO, with it's 3D V-NAND, should be capable of at least double that.
For arguments sake, lets assume it will last for 1 Petabyte. I've written 17TB in 1.5 years, or 11.3TB per year. At that rate, this drive is still going to last at least another 90 YEARS.
So is this really something to obsess over?
Re: Heavy SSD Writes from Firefox
#268Earlier quoted context omitted.
this is the first I heard of this - why is this not a config flag ?
because not losing data is infinitely better than saving your ssd life a couple years. we've had ssds for a long time now. still waiting for one to die on me. meanwhile I'm on my 27th dead spinning disk.
I am one of those people who sets browser to dump all cookies, cache and and history upon closing, so I'm not really sure what data would be lost.
Re: Heavy SSD Writes from Firefox
#269Earlier quoted context omitted.
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.
That would require rewriting the entire directory.
Re: Heavy SSD Writes from Firefox
#270Can this be avoided in FF and Chrome with private tabs?