You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
I had an ADATA SSD die on me recently after less than 1 month power-on time with negligible write throughput. Tons of reallocated sectors and it failed by refusing any further writes (after having previously caused some unexplained FS corruption a day earlier). (thread)
At first I thought this was just a fluke/shitty SSD, but then I remembered something. As part of a hack, for the last 10 days of uptime or so I had a process writing a number to a file a few times per second. Maybe this caused the early death?
If the FTL was utterly terrible, that could've caused it to rewrite the same flash block every time. And after wearing out a block it would go to an alternate... and if those are limited (e.g. indexed by some kind of hash scheme), it would eventually run out of alternates.
Clearly a poor quality SSD implementation in that case... but I wonder if this is what actually happened, as opposed to just a random early failure dud. Perhaps SSD endurance tests should test this use case. Instead of writing over the entire drive, rewrite a single sector.
I bet we'd see wildly different results for different brands, and many deaths well before the specified total drive write endurance. Perhaps a good metric for how good the firmware/FTL algorithm is.
There are plenty of use cases that have this "rewrite one sector repeatedly" pattern - e.g. md-raid metadata includes an event count that basically increases every time the array is written to. I wonder if anyone else has seen this kind of early death and attributed it to this.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
