4 ms·

So not entering read only mode after life end seams like a very dangerus bug that is not realy accepteble. Sidenote: Articles like this always scares the shit

So not entering read only mode after life end seams like a very dangerus bug that is not realy accepteble. Sidenote: Articles like this always scares the shit out of me I have a kingston ssd that has been in my main server for almost 3 years now. The smart data seams to say that it is 100% fine but as it has been on for 24* 365*3 hours that seams unlikely.

rocky1138 12y ago
Yes, but your data is on more than one drive, yes? Presumably you have some sort of RAID setup whereas if the one drive were to truly fail, another would pick up in its place.
- callesgg 12y ago
  Partialy, I do backups of everything that is mine, documents and stuff like that. But restoring the entire system with all tweaks and packets would probably take weeks.
  - bigiain 12y ago
    Why? Give the startlingly low cost of storage these days, I can't imagine a scenario where I'd risk "weeks" of productivity just to save on the raw storage cost of doing a complete (and i my case, bootable) "entire system" backup/archive.
    - callesgg 12y ago
      Is not about money it is about ROI setting up a backup system would be some work and doing backups verifying that they work everything takes time (time to remake system - the time it would take to do backups)/(the risk of failure) I think it is to low
      - bigiain 12y ago
        Fair enough - for me rsync(+bash+cron) and a $80 external usb drive (or just clicking the buttons on TimeMachine on Mac OS X boxen) is a small enough "I" to easily justify the "R" - even for data I could retrieve easily enough if needed. For data I actually care about, I put a lot more effort/money into ensuring I don't lose it.
- rsync 12y ago
  What worries me about raid mirrors on SSDs is that a lot of SSD failures are not due to a part failure, but rather, a pattern failure ... meaning, if you subject this SSD to thus and such series of writes, then it fails. So the worry is, if you mirror an SSD then you could (theoretically) inflict the exact same pattern on them over their lifetime and they would fail simultaneously. That is why all of our SSD boot drives, which are indeed mirrors, are built from two different SSDs ... either two different generations of Intel SSDs (3xx and 5xx for instance) or one Intel and one equivalent Samsung. This way, their behavior cannot become correlated...
  - vidarh 12y ago
    That should concern you for regular drives too. The infamous IBM DeathStar problem was partly resolved with a firmware upgrade that added wear levelling, because the crashes were found to be due to material flaking off the platters when the head remained in the same location, leading to dust in the drive that had a high risk of trigger head crashes so bad it'd strip almost all the material off the glass platters. There's a fun picture on Wikipedia: http://en.wikipedia.org/wiki/HGST_Deskstar#mediaviewer/File:IBM75GXP_Failed_Disks.png http://en.wikipedia.org/wiki/HGST_Deskstar#mediaviewer/File:... We had an array of 10 of them in 2001, and when the first one failed we weren't aware of the problem and didn't think much of it. Then the second failed a week later. The third a week after that. And so on, almost like clock-work until all of them were dead. At the time that array made up enough of our capacity that we couldn't afford to just take it out of rotation until we'd replaced the drives. It's the event that taught me the hard way to always at a minimum mix batches, and preferably models and/or brands (just mixing drives from different batches would've been insufficient with the DeathStar, as far as I remember). As well as to favour multiple smaller arrays... We never lost any data, and the array remained available for the entire time period it took to cycle through all the drives, though.
  - VLM 12y ago
    I've done the same strategy with spinning rust. Only a noob sets up a RAID mirror with two drives same model same mfgr and adjacent serial numbers. I say noob because you only experience this failure mode once before you'll professionally refuse to deploy that way. I have had historical issues with corporate procurement of dell servers with this problem. There is a labor intensive strategy where you throw all the servers into one room and play switcheroo. They'll still be the same model and maybe even the same batch but at least they'll probably not be adjacent serial numbers anymore. A coworker of mine had the strategy of buying RAID servers and then pulling and replacing one drive from all the servers after initial burnin and keeping the yanked drive as as a cold onsite spare. I would gladly pay a little more money to dell or a competitor to put together turnkey servers with carefully intentionally mismatched raid.
sounds 12y ago
Unlike magnetic HDDs it does not matter what the "powered on" time is for an SSD. The most significant factor is the number of blocks erased (and presumably written to). High temps can also affect SSD life.
- dragontamer 12y ago
  http://www.overclock.net/t/1507897/samsung-840-evo-read-speed-drops-on-old-written-data-in-the-drive http://www.overclock.net/t/1507897/samsung-840-evo-read-spee... Incorrect. It has become apparent that the Samsung 840 EVO (Triple-level Cells... 3-bits per cell) have a "powered on" issue. There seems to be significant slowdown when reading data that hasn't been touched for months on those drives.
plaguuuuuu 12y ago
I had an SSD totally brick on me. Not fail to write but just brick. No idea how to recover it
- wazoox 12y ago
  You can't, so far that's how SSDs die. Kroll Ontrack and similar services may get some of the data back, but that's all.
vidarh 12y ago
If the chance of a drive failure scared the shit out of you, it is an indication that you don't trust your recovery processes... Drive failure shouldn't be more than a minor annoyance.

rocky1138 12y ago

Yes, but your data is on more than one drive, yes? Presumably you have some sort of RAID setup whereas if the one drive were to truly fail, another would pick up in its place.

callesgg 12y ago
Partialy, I do backups of everything that is mine, documents and stuff like that. But restoring the entire system with all tweaks and packets would probably take weeks.
- bigiain 12y ago
  Why? Give the startlingly low cost of storage these days, I can't imagine a scenario where I'd risk "weeks" of productivity just to save on the raw storage cost of doing a complete (and i my case, bootable) "entire system" backup/archive.
  - callesgg 12y ago
    Is not about money it is about ROI setting up a backup system would be some work and doing backups verifying that they work everything takes time (time to remake system - the time it would take to do backups)/(the risk of failure) I think it is to low
    - bigiain 12y ago
      Fair enough - for me rsync(+bash+cron) and a $80 external usb drive (or just clicking the buttons on TimeMachine on Mac OS X boxen) is a small enough "I" to easily justify the "R" - even for data I could retrieve easily enough if needed. For data I actually care about, I put a lot more effort/money into ensuring I don't lose it.
rsync 12y ago
What worries me about raid mirrors on SSDs is that a lot of SSD failures are not due to a part failure, but rather, a pattern failure ... meaning, if you subject this SSD to thus and such series of writes, then it fails. So the worry is, if you mirror an SSD then you could (theoretically) inflict the exact same pattern on them over their lifetime and they would fail simultaneously. That is why all of our SSD boot drives, which are indeed mirrors, are built from two different SSDs ... either two different generations of Intel SSDs (3xx and 5xx for instance) or one Intel and one equivalent Samsung. This way, their behavior cannot become correlated...
- vidarh 12y ago
  That should concern you for regular drives too. The infamous IBM DeathStar problem was partly resolved with a firmware upgrade that added wear levelling, because the crashes were found to be due to material flaking off the platters when the head remained in the same location, leading to dust in the drive that had a high risk of trigger head crashes so bad it'd strip almost all the material off the glass platters. There's a fun picture on Wikipedia: http://en.wikipedia.org/wiki/HGST_Deskstar#mediaviewer/File:IBM75GXP_Failed_Disks.png http://en.wikipedia.org/wiki/HGST_Deskstar#mediaviewer/File:... We had an array of 10 of them in 2001, and when the first one failed we weren't aware of the problem and didn't think much of it. Then the second failed a week later. The third a week after that. And so on, almost like clock-work until all of them were dead. At the time that array made up enough of our capacity that we couldn't afford to just take it out of rotation until we'd replaced the drives. It's the event that taught me the hard way to always at a minimum mix batches, and preferably models and/or brands (just mixing drives from different batches would've been insufficient with the DeathStar, as far as I remember). As well as to favour multiple smaller arrays... We never lost any data, and the array remained available for the entire time period it took to cycle through all the drives, though.
- VLM 12y ago
  I've done the same strategy with spinning rust. Only a noob sets up a RAID mirror with two drives same model same mfgr and adjacent serial numbers. I say noob because you only experience this failure mode once before you'll professionally refuse to deploy that way. I have had historical issues with corporate procurement of dell servers with this problem. There is a labor intensive strategy where you throw all the servers into one room and play switcheroo. They'll still be the same model and maybe even the same batch but at least they'll probably not be adjacent serial numbers anymore. A coworker of mine had the strategy of buying RAID servers and then pulling and replacing one drive from all the servers after initial burnin and keeping the yanked drive as as a cold onsite spare. I would gladly pay a little more money to dell or a competitor to put together turnkey servers with carefully intentionally mismatched raid.

sounds 12y ago

Unlike magnetic HDDs it does not matter what the "powered on" time is for an SSD. The most significant factor is the number of blocks erased (and presumably written to). High temps can also affect SSD life.

dragontamer 12y ago
http://www.overclock.net/t/1507897/samsung-840-evo-read-speed-drops-on-old-written-data-in-the-drive http://www.overclock.net/t/1507897/samsung-840-evo-read-spee... Incorrect. It has become apparent that the Samsung 840 EVO (Triple-level Cells... 3-bits per cell) have a "powered on" issue. There seems to be significant slowdown when reading data that hasn't been touched for months on those drives.

plaguuuuuu 12y ago

I had an SSD totally brick on me. Not fail to write but just brick. No idea how to recover it

wazoox 12y ago
You can't, so far that's how SSDs die. Kroll Ontrack and similar services may get some of the data back, but that's all.

vidarh 12y ago

If the chance of a drive failure scared the shit out of you, it is an indication that you don't trust your recovery processes... Drive failure shouldn't be more than a minor annoyance.