Hacker News new | past | comments | ask | show | jobs | submit login

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.




Android Firefox has this set to 10 seconds, rather than the 15 on a desktop.


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


5 tabs isn't very many. If the OP has 40+ tabs open at a time, following that math, it should hit 1GB pretty easily.


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 ;)


And Pale Moon (Firefox fork) to 60.


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.


this was a very insightful comment, thank you!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: