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.
So basically, no, you don't have to worry about this. Essentially, people are complaining that the disks they bought are being used for their intended purpose: making sure your data doesn't disappear on a power loss.
There is also a case of the silly SSHD's or w/e which combine a tiny SSD and a mechanical component which can die considerably faster.
Overall the amount of writes an SSD can handle is tied directly to it's capacity since it determines the amount of average writes per a given time unit that each cell will experience as long as the firmware actually does it's job (in Samsung's case it may very well not do it as they had more than a few firmware screw ups in the past).
This can also more severely affect you if you have a medium sized drive (say 128-256GB) but it's pretty full.
A good SSD's will move things around somewhat to even out the wear but it still increases the amount of writes you have.
If your SSD does have an "even wear" feature when you write 12GB to drive which is say 50% or more full it usually triggers more than 12GB of effective writes in the drive itself as the firmware would move already written data around to ensure that every cell has been written to approximately the same amount (if you say only have 20GB of free space and you write 12GB daily and delete it, your effective writes would be closer to the full capacity of the drive per day than to 12GB).
You also have a lot of embedded/mobile devices which use considerably shittier storage than modern SSD's, you can easily chew through a SD card or a similarly rated flash storage with anywhere between a few 100's of gigs to only a handful of TB's (or a only few times the capacity of the card if buy bargain bin memory cards).
Since these machines are more commonly used these days it's not a feature that should be so quickly obfuscated from the user since it doesn't seem like there is an "intelligence" behind how conservative or not the browser is with writes to local storage.
If you install firefox on an SBC/netbook/microcomputer or even a mobile phone (if this affects the mobile version also) with eMMC/MMC only rated storage 12 gigs a day can and will kill it rather quickly.
Other things like add ons, amount of tabs open and etc. could also affect it.
Would be interesting to see if some one has SBC's with either SD or onboard eMMC rated storage to run this test and see how much is being written too and calculate just how much of the lifespan of the storage is being reduced due to this.
IIRC even the iPhone 6s still uses TLC flash for it's storage, TLC is only good for about 500-1000 P/E cycles, so it needs pretty good capacity overhead and well "TLC" to live long.
In comparison SLC gets you over 100K P/E cycles these days, MLC can get to over 30K.
Also if anyone knows if mobile phones do wear leveling for their eMMC/MMC storage I would love to know that ;)
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).
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.
Do you manually hit the save button every 15 seconds?
Some webapps do this for you. Some do not. Firefox has got your ass covered even for those that do not.
It might be nice if this was tunable via a setting though.
Because you hear the data volume, the function, and you think there has GOT to be a better way
If there is also an associated 12 GB/day of reads then half that estimate (unlikely to be equal due to the nature of the cache). Either way -- not a significant degradation.
Edit: Degradation or not -- i'd personally rather have my drive resources available. In the context switch from firefox the cache process could interfere with loading other data.
Drives that reach >1PB or write endurance are no longer on the consumer market. You can buy them (SLC), but you wont after seeing the price.
You can do nice tests that will last for hundreds of TBs .. until you pause for 24 hours and realize all the data is gone.
[0]http://techreport.com/review/27909/the-ssd-endurance-experim...
840 is especially broken and dramatically slows down when you dont touch the data for >month. The "fix" is firmware silently rewriting everything in the background burning thru the rewrite cycles.
Real lifetimes are often a multitude of the endurance rating, BTW.
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 browser is usually synced to an upstream browser every few minutes - auto saved emails or multi-step web-apps.
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).
[1]: http://www.intel.com/content/dam/www/public/us/en/documents/... section 2.6
You still lose all your data though :(