Possibly related to recent HN issues, see: https://news.ycombinator.com/item?id=32031243
This gives me a strong feeling of general unease and flashbacks to the days of WD hard drives.
Miniscribe RLL disks: destroyer of early PC building firms.
SSD will fail at 40k power-on hours (2021)
121–130 of 276 posts
Re: SSD will fail at 40k power-on hours (2021)
#122.
Re: SSD will fail at 40k power-on hours (2021)
#123One of the dumbest things I have done in my life is buying an SSD and new HDDs to farm Chia. After about a month of farming, the SSD died due to the constant read/writes.
Re: SSD will fail at 40k power-on hours (2021)
#124One of the dumbest things I have done in my life is buying an SSD and new HDDs to farm Chia. After about a month of farming, the SSD died due to the constant read/writes.
Did you make any money?
Re: SSD will fail at 40k power-on hours (2021)
#125One of the dumbest things I have done in my life is buying an SSD and new HDDs to farm Chia. After about a month of farming, the SSD died due to the constant read/writes.
Did you make any money?
Nice one. For your enjoyment have a look at the "all-time" chart.
https://coinmarketcap.com/currencies/chia-network/
While the concept of Chia was interesting at the time and also reminded me of the "smart fridges of silicon valley (the show)", filling up gigabytes with trash data to prove a technical point made me lose interest. Just glad I didn't invest more.
Re: SSD will fail at 40k power-on hours (2021)
#126Earlier quoted context omitted.
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 9 Power_On_Hours 0x0032 055 055 000 Old_age Always - 39676 I'm 300 hours from 40K, time to buy new SSD? is this real?!
I mean, is it the affected model? Have you applied the appropriate firmware update?
I did not find the model info, but thanks!
Re: SSD will fail at 40k power-on hours (2021)
#127Earlier quoted context omitted.
the chance of two SSD's failing at the same time under normal circumstances is extremely slim. So this might actually be a good cause of this incident.
If both SSD's are from the same lot number and one fails, the chances of the second failing go up by a high amount. Both failing at the same time though is extremely rare.
We (as an industry) went through this bad batch madness with the IBM DeskStar 75GXP hard drives, which were affectionately referred to as "IBM Deathstar"[1].
It's rare, but it's not _that_ rare. You have to make the effort to understand why it failed.
I had a situation where I deployed Toshiba SLC SSDs (that were purchased over the course of several months) and a piece of software that synchronized to disk frequently, resulting in about 1GB of writes per hour.
After ~11 months in service, most of the drives died in the same 4 week period. We were astounded that everything failed so close to each other, including instances where both drives in a RAID 1 set were toast.
We did extensive troubleshooting between the failed servers and the remaining servers and figured out that write volume (by proxy of in-service date) was the one predictor of failure. Shortly thereafter, wear leveling and TRIM became things we sought out mentions of when spec'ing out hardware.
Re: SSD will fail at 40k power-on hours (2021)
#128Check your power-on hours: $ sudo smartctl -a /dev/sda | grep -e Power_On_Hours -e ^ID ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 9743 Just looking at the raw value, it seems to be 9'743 hours in my case
Re: SSD will fail at 40k power-on hours (2021)
#12940000 (or even 40960) seems an odd number to fail at. 64k or 32k would make the cause pretty obvious, but 40000 doesn't seem all that round in binary. Perhaps a 12-bit counter incrementing every 10h? This is puzzling. Of course, I am also entertaining the possibility that no one thought they would be in use for this long, which would certainly be evidence of planned obsolescence.
From a related issue with a different vendor: "The fault fixed by the Dell EMC firmware concerns an Assert function which had a bad check to validate the value of a circular buffer’s index value. Instead of checking the maximum value as N, it checked for N-1. The fix corrects the assert check to use the maximum value as N." https://www.anandtech.com/show/15673/dell-hpe-updates-for-40... Why the MAX value would be in…
From my reading, it's checking the maximum index into the circular buffer. That is, when it hits the end of the circular buffer, there's an assertion to check that they're properly wrapping the index back to the start of the buffer, but the assertion has an off-by-one error.
I presume you find a lot of circular buffers in SSD firmware, for wear-leveling reasons. Samsung's NILFS and NILFS2 are structured as circular buffer append-only logs, at least partly to avoid trusting the firmware wear-leveling.
Re: SSD will fail at 40k power-on hours (2021)
#130Earlier quoted context omitted.
If it were 53, I'd wonder "are they storing the time in the integer part of a double precision float?" That wouldn't go negative, it'd just start absorbing increments without changing the value. Though that might cause a divide by zero? What could cause unexpected behavior at 57 bits? Perhaps storing fractions of an hour, like incrementing it every 1/16th of an hour and calculating a relative rate of change, causing…
Packing a type flag into the upper bits of a 64 bit value is a reasonably common optimisation in dynamic language implementations (because it lets you use unboxed number arithmetic).
Or sometimes the lower bits, as at least used to be the case for integers in v8. (Also OCaml, but that's not dynamically typed. It simplifies the garbage collector to at least some times not require a pointer map for each type, just a flag in the object header to indicate if it contains any pointers, and then everything that isn't ints or pointers needs to be boxed.)