I just built a new PC with SSDs, and switched back to Firefox. Even with 16GB of RAM on an i3-2120, Firefox still hiccups and lags when I open new tabs or try to scroll.
This new issue of it prematurely wearing out my SSDs will just push me to Chrome. Hopefully it doesn't have the same issues.
Look out for addons. Electrolysis will still not work with many of them. I force enabled it a few weeks ago, and discovered that it's disabled for good reasons.
Heh. Tried that out and while it didn't affect stability it made switching tabs take 2-3s on a haswell system. By disabling all extensions with it I was able to somewhat match performance of non-multiprocess.
Nice idea but a load of useful extensions don't work with it. Of extensions I use noscript and 1password were the main ones, but around half were tagged as not compatible.
My home desktop is an i5-1620 with 64G RAM running Ubuntu 16.04, and Firefox just hiccups and lags, period. It is sad.
I need to find time to experiment with Chrome while blocking all the Google chatter to see how functional it remains without being able to tattle to the mothership (otherwise I won't use it).
Try out the Pale Moon firefox forks. I'm running it on an old core2duo 6400 (2.13 GHz) with 8 GB ram. I have over 700 tabs in my session right now with at least 300 of them fully loaded. It's using less than 3GB ram. And it's fast/snappy with smooth scrolling.
This is a far superior solution to fiddling with configuration options in each individual product to avoid wearing down your SSD with constant writes. Murphy's law has it such hacks will only be frustrated by next version upgrade.
And no, using Chrome does not help. All browsers that use disk caching or complex state on disk are fundamentally heavy on writes to an SSD. The amount of traffic itself is not even a particularly good measure of SSD wear, since writing a single kilobyte of data on an SSD can not be achieved on HW level without rewriting the whole page, which is generally several megabytes in size. So changing a single byte in a file is no less taxing than a huge 4 MB write.
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.
Samsung's low cost line is under warranty up to 40TB/year. Tests have shown that the actual drive lifetime is several times that.
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.
Not everyone buys Samsung, there are a lot of cheap SSD's out there that are rated for only a handful of TB's a year.
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.
Firefox's session restore code was recently rewritten. Given that Pale Moon is based on an outdated fork, it's not clear the behavior is comparable, or that the setting means the same.
Android suspends backgrounded applications, and will kill them at will, so that actually makes a lot of sense: you have less risk of data loss, and the write issue doesn't exist unless you leave the browser in the foreground 24/7 (and the phone unlocked with the screen on etc).
I don't know what this translates too for a mobile device, I don't know if it stores the same data, and how does the fact that mobile sites tend to be light affects it.
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 ;)
I think there's something wrong with OP's Firefox. Looking at IO_WBYTES in htop I have exactly 42MB written after 2h11min of operation with 5+ tabs opened at any given time. I have my sessionstore.interval set to 1min. Assuming that if it ran 4x faster (default) it would write 4x more it should be 168MB in 2h of operation, whereas OP reports 1GB every 2h.
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.
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.
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).
If the data hasn't changed during the last interval, then it doesn't rewrite the file. The article mentions loading a couple of dozen pages that are probably all pinging a dozen ad servers every 15 seconds, updating their cookies and localstorage with the results, etc. It all adds up. If you really want to solve the problem, use an ad blocker, or push the pages you visit to remove the bloat.
If you can get a petabyte of r/w out of an SSD then 12 GB/day (of writes only) will exhaust the device in 228 years (1 PB * 1000 TB/PB * 1000 GB/TB / 12 GB/Day / 365 Days/Year).
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.
It was the 840 Pro that went 2.4 terabytes during a drive test that ended in 2015[0]. That was a 21nm tech. I think the endurance is better than you think.
afair this test was run 24/7 with no power down time. Earlier test (the one with 830? I think he moved computer mid test and had to power everything down) showed drives look healthy until you let them sit offline for a while, then it turns out all data evaporated.
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.
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.
You're still using 1/4 of your write unendurable for your fricking web browser. And exceeding the endurance rating can make you ineligible for warranty service/replacement of the drive.
> 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 browser is usually synced to an upstream browser every few minutes - auto saved emails or multi-step web-apps.
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).
TBH, I wouldn't even have thought about searching history... also, every change for every window would save history requiring a sync... And for some things, cookies, sessionStorage, localStorage, websql and the like are pretty important too.
The web browser is basically everything I do, though. My email is in it, my code review is in it, my IM is in it, on some of my machines my terminals are in it (via the Chrome mosh app).
Email/code review/IM/terminal doesn't justify 12GB of writes per day (and attendant hit to drive endurance/battery life). Those are lightweight activities. Emacs can do all those things and it doesn't write to disk unless you tell it to. Heck, even bloated beyond belief Outlook + Visual Studio + Skype + PowerShell wouldn't create anywhere near that kind of background activity.
Those applications have the benefit that they know exactly what the user data is, what their own state is, and how much of that is due to user input. The browser doesn't have that advantage. For one, state is coming off of the network all the time.
What does "justify" mean here? My web browser does them in a lot more useful fashion to me than Emacs would - in other words, it is worth 12GB of writes per day for me to get these into my web browser instead of into Emacs. Am I wrong for thinking that this is a good tradeoff?
Did you actually decide to make this tradeoff? Did Firefox at some point explain it was going to do 12GB of writes per day and you clicked the button that said yes?
Anybody buying a drive so cheap it can't handle Firefox is probably putting the drive in a machine so cheap that it will only be lasting 3-4 years maximum anyway.
Even better just disable session restore entirely - Browser.sessionstore.enabled - Since Firefox 3.5 this preference is superseded with setting browser.sessionstore.max_tabs_undo and browser.sessionstore.max_windows_undo to 0.
As I understand this feature is there so if the browser crashes it can restore your windows and tabs - I don't remember having a browser crash on me since the demise of Flash.
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.
Hmm I really haven't had FF or Chrome crash on me since a long time - I do browse a lot. I can't be that lucky. I am not saying it doesn't happen - I am saying it's so infrequent that it's just better to deal with it when it happens instead of killing your SSD with constant writes of 15GB per day. Most people don't do anything that needs to be recovered by a crashed browser.
Who really cares about restoring browser state? Maybe I lose part of an HN or Facebook post I'd been writing, but that's it. The feature should be opt-in, IMHO.
I made a simple firefox/chrome extension for people like you and me that horde tabs. You might find it useful to find tabs and quickly navigate to them by clicking on the link in the list. It's free and open source. The github page has a gif showing usage.
Anyway I used an extension like this for awhile, called session buddy. But now I just use control+D and bookmark all my tabs. Then you get bookmark syncing, and you can save your tabs when you export bookmarks, or wget them to have a local archive, etc. It's just more convenient, and one less extension I have to worry about stealing my personal information or bugging and corrupting my data.
That's fair and the extension is not for everyone. It's not really meant for saving sessions or anything like that it's more for finding lost tabs in a sea of windows like I typically have. This is more for tabs that are not worth saving to bookmarks but that you have open for a long time as a transient bookmark.
FWIW, Mozilla looks at all extensions before fully approving them and the app is fully open source and fairly easily vetted if people are worried about that sort of thing.
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.
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.
I had about ~250 tabs and i closed them now. Bookmarked before. This "feature" of FF is rly cucking. I have tons of GB written to my SSD without any benefit (i not a "safety critical user"). And the worst thing is, all of this data was written into 40 GB of SSD space.
this session restore feature, lets just save the urls in a list. that data structure cant be GB of GB right! ;) I think thats enough for the, lets say, typical FF user.
Now, that i know about this issue, i will bring down my tab usage to no more than 10 tabs.
Hadn't thought about it until now, but this feature may be why I don't see "I wrote you a long message but accidentally closed the tab / hit the back button / my computer crashed and I lost it, so here's the highlights I remember" emails from friends and family anymore. I would much rather discover this caveat and opt out than expect my grandmother to know it's even possible to opt in.
At this point, isn't that responsiblity larged handled by server-based autosave? GMail / Google Docs being the big ones, I assume FB and other social networking sites do the same.
I really care about it. I take advantage of it everyday. I close tabs and use ctrl+shift+t to reopen them, I reopen my browsers previous state after closing it, and after computer crashes I don't have to worry about losing any of my precious tabs.
Why should it save the whole page when it only needs to remember the URL? At most, maybe also any form data you have entered. Small enough to keep thousands of pages in memory.
It doesn't save the whole page. Just the url, scrolling position, form data and session cookies. If you're browsing with 500 tabs, most of which contain nested frames, including Facebook "Like" icons and the like, that's actually quite a lot.
> I don't remember having a browser crash on me since the demise of Flash.
Just try browsing reddit with the RES extension or streaming heavy data for a few seconds (like a server side PDF processor that takes more than 30 seconds to finish, it's the same old behavior of blocking JS dialogs from years ago, white screen of death). When I'm using a iGPU (512MB) and I open some heavy images in sequence the browser crashes after a certain amount of time but this time it freezes the entire computer for a few seconds, so I suspect it's OOM (iGPU). I never bothered looking for a solution, nowadays I don't even care when my browser ocasionally crashes. My overall desktop (software) experience gets worse every year so I have gone used to it.
But Firefox still is my favorite browser and I wouldn't trade it for anything else!
Yeah that's the difference - I only use few well known extensions like uBlock Origin, Self Destructing Cookies, Lastpass and Decentraleyes. No trouble with any PDFs either. Anyway this is getting off track with the crashes or not - my point was even if it crashes it is no big deal if you can't restore - just reopen will work in most cases.
I need to regularly kill firefox. I just did in fact. It didn't technically crash, but it becomes totally non-responsive for seconds at a time. Maybe it is a misbehaving plugin and not ff, but the effect is the same.
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 disc the deltas every n minutes using rsync. Been using this for years. You can also manually alleviate some of this by setting up a tmpfs and symlink .cache to it.
`mount -l` shows a filesystem of type `overlay` for each browser (in my case, chromium, chrome, firefox). Range from 50MB to 200MB. I have it to sync to disc every 15min - so I reckon it empties out the ram whenever it syncs. I've never had a problem (8GB of ram on the machine I initially installed it on) so I haven't watched to see what the max size is. The developer [1] is great - issues are resolved very quickly.
Launchpad is such a shitty website, aimed at Ubuntu and only Ubuntu, links to source code or more information are nowhere to be found...
Searching on Github, this seems to be it. Turns out, there's releases for Arch, Debian, etc. and it's even in the repositories. No need to add a ppa. https://github.com/graysky2/profile-sync-daemon
For Debian and co:
$ apt-cache show profile-sync-daemon
$ sudo apt-get install profile-sync-daemon
I've long gotten used to "bird" doing it's thing (something with the cloud I guess). But how can a twitter client write 3GB (while I'm not even actually using it?)
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).
This will copy /path/source to /path/dest/$NEW_BACKUP (which is a time stamped folder). But it will take into account the previous backup. If a file hasn't changed, it will create a hard link. If it changed, it will then copy the whole file.
And that's it.
Since it's the name is a time stamp. When you need to restore, just read ./prev_backup or just list the directory content, sort it and read the last entry.
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.
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.
>The reality is that even with fairly heavy use, most of them will far outlive the computers they're in.
I'm not sure what the lifetime of a computer is. In my family, we are still occasionally running machines from circa 1995. They work fine. When should I stop using my MacBook? The only reason I'd stop is if it died in a way that can't be cheaply fixed.
1995 is a stretch for anything modern but I have kids playing Minecraft on Pentium 4’s (with decent graphic cards though - that is the critical part). These boxes would have been new around 2003 or so.
I'm curious what useful work such a computer can perform, given that a typical 1995 computer had a 33 MHz processor, 8 megs of RAM and 1 gigabyte of hard disk space.
The warranty on your EVO is just 150 TBW. The older generations typically had better endurance, the newer generations are more dense (cheaper to produce) but less durable.
If you keep with 17 TB per one and half year your SSD should be OK for your for at least next 11 years.
Yes, but endurance tests almost invariably show that the warranty ratings are extremely conservative. The 1TB 850 PRO (which uses exactly the same NAND chips as the 850 EVO, just a different controller) has been endurance tested to more than 7 Petabytes. See: http://packet.company/blog/
The older generations typically had better endurance, the newer generations are more dense (cheaper to produce) but less durable.
That was true when comparing MLC flash to TLC. But the 850 EVO and PRO use 3D V-NAND, which has significantly more endurance than previous-generation TLC. This seems to be confirmed by endurance tests.
your SSD should be OK for your for at least next 11 years
The warranty runs out after 5 years, anyway. But that does not mean it will suddenly stop working on that date!
No, you're wrong. The 850 PRO uses MLC while the EVO uses TLC. But given that they're both constructed on Samsung's 3D-VNAND technology, their endurance is still much higher than the competitors out there.
It's not "much" higher, actually, 3D MLC as implemented by Samsung is just "up to twice" better than the planar MLC given the same die area and capacity:
"Samsung V-NAND provides up to twice the endurance of planar NAND."
But if the size of the cell drops, the number of P/E cycles drops. Samsung's endurance declarations are real and to be believed, they initially used bigger cells than some of their other chips (or competitors), but Samsung engineers know what they do, that "some tests" achieved "much more" can be either an accident or due to the errors in the test methodology (and I very much suspect the later, because it also allows the accidents to be taken as the "success"). At the time these SSDs appeared, Samsung declared twice less TBW than they do now, so now the declared endurance is surely not too pessimistic, but based on the real knowledge of what's inside.
Yes, you're right. But I don't expect an EVO to last for a full 7 PB of writes like the PRO did. But even if it lasts a fraction of that (say, approx 1 PB, which previous generation 840 EVO was able to achieve) then it's still 90 years of life at current usage levels! A (1 TB) 850 PRO would last over 600 years!
In all likelihood the drive will never get anywhere near any of these values - it'll be replaced with newer, better tech at some point. It may then get used for a backups or secondary storage, but in those scenarios the daily writes will drop enormously.
Most of the SSD failed before a petabyte... and started encountering lots of errors before that (forget about the Samsung Pro series which is the only one that survived till its multi-petabyte end).
Do you ever miss the upside of all that persistence? I find my history useful, I find continually re-logging in a pain (obviously excepting the kind of sites where I don't want my login to persist i.e. financial etc).
However I also only close my browser once every couple of weeks as well. System updates etc.
that is the beauty of it. You can disable. Be glad you have firefox and not only IE or chrome (where you can't disable all the things)
But for 99% of the users, they want it.
Heck, anecdote for anecdote: the very first thing i do on new machines is to open up firefox, go to settings, set the browser to startup with my previous session's tabs.
beware! profile-sync-daemon erased my browser profiles upon first run under Ubuntu Xenial due to apparent bug in eCryptfs support (and how /home was mounted). Report was submitted to the developer.
Been using on my system ever since I started running everything from my USB drive... to prevent excessive freezing twice a minute. On NixOS, add the following two lines to your configuration.nix:
The OP is complaining about excessive write traffic, which wastes power, steals disk-time from other applications, and may wear out SSDs prematurely.
A large profile file does not imply excessive write traffic, so it's not clear from your report that Chrome is hitting the same problem at all. Definitely worth watching, but big-file != excessive-writes.
Nightly Portable might have this particular setting changed, because the lifetime of random USB sticks is surely going to be much less than a real SSD.
I'm not seeing these numbers either and I'm running Firefox 49. In the resource monitor, I see firefox writing to disk 10kB every 15 sec. I bet there is something else to the story of this guy.
Doing all this work is also probably burning battery life. An SSD can use several watts while writing, versus as low as 30-50 milliwatts at idle (with proper power management).
I seriously dislike Firefox, but must use it at work due to browser incompatibility issues with Chrome and sites I use heavily. Anything that makes the experience better is much appreciated.
If is perfectly valid for you to dislike Firefox. But in the context of this post it seems that you assume Chrome is better than FF in terms of disc usage. Do you have any data to back that claim up?
Maybe because they would rather not have their ssd constantly being hit? Seems reasonable to me to move this is you have concerns about the longevity, or maybe IO bottlenecks.
Yep, I have a brand new SSD drive that over the course of a few months accumulated several TERAbytes (yes - TERA) of writes directly attributable to the default FF browser session sync interval coupled with the fact I leave it open 24/7 with tons of open tabs.
Once I noticed that excessive writes were occurring, it was easy for me to identify FF as the culprit in Process Hacker but it took much longer to figure out why FF was doing it.
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? Seems like it should only write after a user action or if the open page writes to storage? Even if it was necessary to write continually while idle, how could it possibly consume so much data in such a short period of time?
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 storing the data persistently, it uses the persistent storage, i.e. your harddrive. For the HN crowd, that's going to be an SSD. The SSD can easily deal with the resulting write traffic with negligible effect on its lifetime - I have no idea why people even think this is an issue.
Seems like it should only write after a user action or if the open page writes to storage
Webpages can change their contents or state without user interaction.
Webpages are also big and bloated. Storing a little data, all the time, 24/7, adds up over time to a surprisingly large number.
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, then to me that is a bug.
EDIT: Also, it seems like when I remember restoring a browser session after a crash, all the tabs get reloaded, not restoring the page state, just the tabs/URLs (ie. browser makes new request(s) for each restored tab). I usually use Chrome though, not sure if this has happened to me on Firefox.
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.
> but shouldn't the browser only write to disk when that actually happens
The problem is that it's happening continuously. Any page with analytics or ad engines (I'd guess easily 95% of the top visited web) is continually logging how long you've been on the page, scroll position, idle time, etc. And then setting a cookie to remember the session info/last time it was updated.
It would be interesting to see what installing an ad blocker would do to these numbers.
I have no idea why people even think this is an issue.
There is some element of slippery-slope. People say, "So what if your web browser uses 8GB of RAM for six tabs, you've got 16GB!". But I'd argue if every piece of software squandered RAM with such abandon, your machine would quickly choke.
It's also got some good shock value, like the one-paragraph web article that overloads your phone & generates 75MB of traffic.
The interesting question here is, why is the browser writing data to disk at this rate?
If it's genuinely receiving new data at this rate, that's kind of concerning for those of us on capped/metered mobile connections. The original article mentions that cookies accounted for the bulk of the writes, which is distressing.
If it's not, using incremental deltas is surely a no-brainer here?
I have been running Firefox for a long time with an LD_PRELOAD wrapper which turns fsync() and sync() into a no-op.
I feel it's little antisocial for regular desktop apps to assume it's for them to do this.
Chrome is also a culprit, a similar sync'ing caused us problems at my employer's, inflated pressure on an NFS server where /home directories are network mounts. Even where we already put the cache to a local disk.
At the bottom of these sorts of cases I have on more than one occasion found an SQLite database. I can see its benefit as a file format, but I don't think we need full database-like synchronisation on things like cookie updates; I would prefer to lose a few seconds (or minutes) of cookie updates on power loss than over-inflate the I/O requirements.
It's probably best to just disable sessionstore if you don't want it, as overwriting fsync would disable it for all operations Firefox might use, not just sessionstore.
So you're relying on the implicit write barrier many filesystems supply that ensures that the contents of a file hit the disk before a renaming of that file does. That's adequate, but I'd personally checksum the file instead of relying on corruption causing JSON to become structurally invalid.
Well, it's better when this write barrier happens (which is not true on ext4, iirc), but we rely mostly on the the fact that operating systems flush automatically within 20 seconds (I don't remember the actual numbers, but I'm almost sure it's actually within at most 5 second in practice).
Checksums/signatures would be more precise, indeed.
It's a problem if it's not configured appropriately. Remember the use of SQLite is entirely internal to the application; it's not for users to know how it's used, or even that it's used at all.
In the case of a Chrome (many versions ago; may have changed), we manually tweaked that pragma in all our users profiles. I recall something like an order of magnitude reduction of pressure on the /home server.
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...
Putting aside how this may not be all that bad for most SSD's, does anyone know when this behavior started?
Firefox really started to annoy me with its constant and needless updates a few months back; the tipping point being breaking almost all legacy extensions (in 46, I believe). This totally broke the Zend Debugger extension, the only way forward would be to totally change my development environment. I'm 38 and now, and apparently well beyond the days when the "new and shiny" hold value. These days I just want stability and reliability.
Firefox keeps charging forward and, as far as I can tell, has brought nothing to the table except new security issues and breaking that which once worked.
I haven't updated since 41 and you know what, it's nearly perfect. It's fast, does what I need it to do, and just plain old works.
Firefox appears to have become a perfect example of developing for the sake of.
Wikipedia claims the session restore features was added with 2006's 2.0 release. That's what I would have guessed, since that release was (famously) a giant step backwards in performance, which was never really addressed except by waiting for hardware to improve.
I'm holding out hope that whoever's responsible for Firefox abandoning "good, light, cross-platform web browser" as its differentiator stays away from Servo, at least for a while. That's a niche that's unserved currently, AFAIK.
Much of the recent breakage was to introduce essential features that users have been loudly asking for for years, such as multi-process support and content processes in a security sandbox.
If you're intentionally running very old versions which by now have published exploits, then I can see that these are not things you would consider important.
It's exactly the opposite of this. Have you read through the FF update notes? The web standards are a moving goalpost - constantly evolving.
On top of that they've been slowly landing incremental improvements to Electrolysis that have allowed them to turn it on for more and more users without big risks to stability. You can't do that for a browser with "big bang" releases every year.
In the last years I think it's been shown that the only model that works for browsers is "evergreen".
360 comments
[ 2.1 ms ] story [ 327 ms ] threadI just built a new PC with SSDs, and switched back to Firefox. Even with 16GB of RAM on an i3-2120, Firefox still hiccups and lags when I open new tabs or try to scroll.
This new issue of it prematurely wearing out my SSDs will just push me to Chrome. Hopefully it doesn't have the same issues.
https://wiki.mozilla.org/Electrolysis
I need to find time to experiment with Chrome while blocking all the Google chatter to see how functional it remains without being able to tattle to the mothership (otherwise I won't use it).
I'd imagine someone like the above poster would be concerned about that. At least I know I am
This is a far superior solution to fiddling with configuration options in each individual product to avoid wearing down your SSD with constant writes. Murphy's law has it such hacks will only be frustrated by next version upgrade.
And no, using Chrome does not help. All browsers that use disk caching or complex state on disk are fundamentally heavy on writes to an SSD. The amount of traffic itself is not even a particularly good measure of SSD wear, since writing a single kilobyte of data on an SSD can not be achieved on HW level without rewriting the whole page, which is generally several megabytes in size. So changing a single byte in a file is no less taxing than a huge 4 MB write.
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 ;)
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
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).
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.
You still lose all your data though :(
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
As I understand this feature is there so if the browser crashes it can restore your windows and tabs - I don't remember having a browser crash on me since the demise of Flash.
And yes, there are browser crashes without Flash
I stopped using Edge because it only saves your tab session if you turn off the PC, not if you quit the browser.
Mind you, for a while I ran Firefox using a RAMdisc for the profile simply because all that flushing makes a big negative impact on PC performance.
Chrome Extension: https://chrome.google.com/webstore/detail/tabist/hdjegjggiog...
Firefox Extension: https://addons.mozilla.org/en-US/firefox/addon/tabist/
source code: https://github.com/fiveNinePlusR/tabist
Let me know if you find it useful or have any suggestions.
Anyway I used an extension like this for awhile, called session buddy. But now I just use control+D and bookmark all my tabs. Then you get bookmark syncing, and you can save your tabs when you export bookmarks, or wget them to have a local archive, etc. It's just more convenient, and one less extension I have to worry about stealing my personal information or bugging and corrupting my data.
FWIW, Mozilla looks at all extensions before fully approving them and the app is fully open source and fairly easily vetted if people are worried about that sort of thing.
Thanks for the feedback!
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!
this session restore feature, lets just save the urls in a list. that data structure cant be GB of GB right! ;) I think thats enough for the, lets say, typical FF user.
Now, that i know about this issue, i will bring down my tab usage to no more than 10 tabs.
The internet allows it to do that.
Just try browsing reddit with the RES extension or streaming heavy data for a few seconds (like a server side PDF processor that takes more than 30 seconds to finish, it's the same old behavior of blocking JS dialogs from years ago, white screen of death). When I'm using a iGPU (512MB) and I open some heavy images in sequence the browser crashes after a certain amount of time but this time it freezes the entire computer for a few seconds, so I suspect it's OOM (iGPU). I never bothered looking for a solution, nowadays I don't even care when my browser ocasionally crashes. My overall desktop (software) experience gets worse every year so I have gone used to it.
But Firefox still is my favorite browser and I wouldn't trade it for anything else!
Yeah that's the difference - I only use few well known extensions like uBlock Origin, Self Destructing Cookies, Lastpass and Decentraleyes. No trouble with any PDFs either. Anyway this is getting off track with the crashes or not - my point was even if it crashes it is no big deal if you can't restore - just reopen will work in most cases.
RES is more well known (in terms of number of downloads/users) than 50% of your listed extensions, for the record.
I don't like the anxiety of opening Firefox in front of someone, and wondering if my previous tabs will pop up.
At work, I routinely have something like 30-40 tabs open, if my browser can restore the session after a crash, that is very valuable to me.
I'll see if it has any affect on my laptop's battery life and fan usage.
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 disc the deltas every n minutes using rsync. Been using this for years. You can also manually alleviate some of this by setting up a tmpfs and symlink .cache to it.
[1] https://launchpad.net/~graysky/+archive/ubuntu/utils [2] https://github.com/graysky2/profile-sync-daemon
EDIT: Add link, grammar
EDIT2: Add link to source
[1] https://github.com/graysky2/profile-sync-daemon
overlaid 2.0G 128M 1.9G 7% /run/user/1000/codemac-firefox-3ckuo4v7.default
Searching on Github, this seems to be it. Turns out, there's releases for Arch, Debian, etc. and it's even in the repositories. No need to add a ppa. https://github.com/graysky2/profile-sync-daemon
For Debian and co:
See eg https://launchpad.net/openstack, https://launchpad.net/inkscape, https://launchpad.net/shutter etc
And that's it.
Since it's the name is a time stamp. When you need to restore, just read ./prev_backup or just list the directory content, sort it and read the last entry.
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?
I'm not sure what the lifetime of a computer is. In my family, we are still occasionally running machines from circa 1995. They work fine. When should I stop using my MacBook? The only reason I'd stop is if it died in a way that can't be cheaply fixed.
Pretty sure it's not 21 years, c'mon...
If you keep with 17 TB per one and half year your SSD should be OK for your for at least next 11 years.
Yes, but endurance tests almost invariably show that the warranty ratings are extremely conservative. The 1TB 850 PRO (which uses exactly the same NAND chips as the 850 EVO, just a different controller) has been endurance tested to more than 7 Petabytes. See: http://packet.company/blog/
The older generations typically had better endurance, the newer generations are more dense (cheaper to produce) but less durable.
That was true when comparing MLC flash to TLC. But the 850 EVO and PRO use 3D V-NAND, which has significantly more endurance than previous-generation TLC. This seems to be confirmed by endurance tests.
your SSD should be OK for your for at least next 11 years
The warranty runs out after 5 years, anyway. But that does not mean it will suddenly stop working on that date!
It's not "much" higher, actually, 3D MLC as implemented by Samsung is just "up to twice" better than the planar MLC given the same die area and capacity:
http://www.samsung.com/semiconductor/minisite/ssd/v-nand/tec...
"Samsung V-NAND provides up to twice the endurance of planar NAND."
But if the size of the cell drops, the number of P/E cycles drops. Samsung's endurance declarations are real and to be believed, they initially used bigger cells than some of their other chips (or competitors), but Samsung engineers know what they do, that "some tests" achieved "much more" can be either an accident or due to the errors in the test methodology (and I very much suspect the later, because it also allows the accidents to be taken as the "success"). At the time these SSDs appeared, Samsung declared twice less TBW than they do now, so now the declared endurance is surely not too pessimistic, but based on the real knowledge of what's inside.
In all likelihood the drive will never get anywhere near any of these values - it'll be replaced with newer, better tech at some point. It may then get used for a backups or secondary storage, but in those scenarios the daily writes will drop enormously.
Most of the SSD failed before a petabyte... and started encountering lots of errors before that (forget about the Samsung Pro series which is the only one that survived till its multi-petabyte end).
If a 250GB 840 EVO can get to 800TB without errors, then I'd expect a 500GB 850 EVO to reach 1 PB, easily.
A 500GB 850 EVO has newer-generation, more durable NAND endurance and twice the capacity to work with.
However I also only close my browser once every couple of weeks as well. System updates etc.
But for 99% of the users, they want it.
Heck, anecdote for anecdote: the very first thing i do on new machines is to open up firefox, go to settings, set the browser to startup with my previous session's tabs.
I guess doing something like this on Windows is too much to hope for, but does anyone know how to do this sort of thing on the Mac?
The OP is complaining about excessive write traffic, which wastes power, steals disk-time from other applications, and may wear out SSDs prematurely.
A large profile file does not imply excessive write traffic, so it's not clear from your report that Chrome is hitting the same problem at all. Definitely worth watching, but big-file != excessive-writes.
There's an edit at the end of the article:
> Currently in the middle of a Chrome Version 52.0.2743.116 m test. We have been able to see a pace of over 24GB/ day of writes on this machine...
24GB is higher than the 10-12 he was complaining about from Firefox, even.
Because FF may die but the OS will save it later. That's fine
Not every write to a file means a write to disk
Maybe moving this folder to a HDD should suffice.
So I think the session restore is almost always used in a case where firefox crashed, but the system is fine.
Once I noticed that excessive writes were occurring, it was easy for me to identify FF as the culprit in Process Hacker but it took much longer to figure out why FF was doing it.
I was thinking the same and will do so myself, if no-one else reports doing so.
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 storing the data persistently, it uses the persistent storage, i.e. your harddrive. For the HN crowd, that's going to be an SSD. The SSD can easily deal with the resulting write traffic with negligible effect on its lifetime - I have no idea why people even think this is an issue.
Seems like it should only write after a user action or if the open page writes to storage
Webpages can change their contents or state without user interaction.
Webpages are also big and bloated. Storing a little data, all the time, 24/7, adds up over time to a surprisingly large number.
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, then to me that is a bug.
EDIT: Also, it seems like when I remember restoring a browser session after a crash, all the tabs get reloaded, not restoring the page state, just the tabs/URLs (ie. browser makes new request(s) for each restored tab). I usually use Chrome though, not sure if this has happened to me on Firefox.
Yoric pointed out here that not being able to save tabs individually is a weak point of the current implementation.
The problem is that it's happening continuously. Any page with analytics or ad engines (I'd guess easily 95% of the top visited web) is continually logging how long you've been on the page, scroll position, idle time, etc. And then setting a cookie to remember the session info/last time it was updated.
It would be interesting to see what installing an ad blocker would do to these numbers.
There is some element of slippery-slope. People say, "So what if your web browser uses 8GB of RAM for six tabs, you've got 16GB!". But I'd argue if every piece of software squandered RAM with such abandon, your machine would quickly choke.
It's also got some good shock value, like the one-paragraph web article that overloads your phone & generates 75MB of traffic.
If it's genuinely receiving new data at this rate, that's kind of concerning for those of us on capped/metered mobile connections. The original article mentions that cookies accounted for the bulk of the writes, which is distressing.
If it's not, using incremental deltas is surely a no-brainer here?
Might be surprisingly hard or inefficient given that you're trying to capture "webpage state". Think about React sites etc.
I feel it's little antisocial for regular desktop apps to assume it's for them to do this.
Chrome is also a culprit, a similar sync'ing caused us problems at my employer's, inflated pressure on an NFS server where /home directories are network mounts. Even where we already put the cache to a local disk.
At the bottom of these sorts of cases I have on more than one occasion found an SQLite database. I can see its benefit as a file format, but I don't think we need full database-like synchronisation on things like cookie updates; I would prefer to lose a few seconds (or minutes) of cookie updates on power loss than over-inflate the I/O requirements.
For completeness, this is probably the eatmydata command.
In my case it was not SSD wear I wanted to reduce, but the short pauses during interactive use.
Edit Double-checked in the code: I'm right, it doesn't.
Edit If you're interested in how Session Restore improves the safety of its writes without using sync()/fsync(), the details are on my blog: https://dutherenverseauborddelatable.wordpress.com/2014/06/2...
Checksums/signatures would be more precise, indeed.
http://www.sqlite.org/pragma.html#pragma_synchronous
In the case of a Chrome (many versions ago; may have changed), we manually tweaked that pragma in all our users profiles. I recall something like an order of magnitude reduction of pressure on the /home server.
Basically chattr +i on a whole bunch of its files and databases, and everything's fine again...
Chrome was also pretty crappy in 2003. /s
Firefox really started to annoy me with its constant and needless updates a few months back; the tipping point being breaking almost all legacy extensions (in 46, I believe). This totally broke the Zend Debugger extension, the only way forward would be to totally change my development environment. I'm 38 and now, and apparently well beyond the days when the "new and shiny" hold value. These days I just want stability and reliability.
Firefox keeps charging forward and, as far as I can tell, has brought nothing to the table except new security issues and breaking that which once worked.
I haven't updated since 41 and you know what, it's nearly perfect. It's fast, does what I need it to do, and just plain old works.
Firefox appears to have become a perfect example of developing for the sake of.
source: http://www.ghacks.net/2008/07/09/change-the-session-store-in...
I'm holding out hope that whoever's responsible for Firefox abandoning "good, light, cross-platform web browser" as its differentiator stays away from Servo, at least for a while. That's a niche that's unserved currently, AFAIK.
If you're intentionally running very old versions which by now have published exploits, then I can see that these are not things you would consider important.
I'm now running the latest version of FF, but still able to use my plugin.
It's exactly the opposite of this. Have you read through the FF update notes? The web standards are a moving goalpost - constantly evolving.
On top of that they've been slowly landing incremental improvements to Electrolysis that have allowed them to turn it on for more and more users without big risks to stability. You can't do that for a browser with "big bang" releases every year.
In the last years I think it's been shown that the only model that works for browsers is "evergreen".
Anyone got ideas on that?