Die dingen hebben niet het eeuwige leven, maar waarschijnlijk tegen de tijd dat je hem wel moet vervangen ben je allang aan een ander systeem toe. Let wel, een mechanische schijf zal het je pas laten weten net voordat deze kapot gaat, of helemaal niet en je staat voor een verrassing. En mechanisch heeft nu eenmaal de eigenschap meer mechanische complexiteit te bevatten, vatbaar is voor trillingen en dus meer point of failures kent en dus de alle kans heeft niet zo lang als de SSD te leven.
Nu is het wel zo dat een SSD ook abrupt kan komen te overlijden, dat percentage zegt ansich niet zo veel behalve dat dit de officiële opgegeven levensduur is van de SSD van de fabrikant, maar uit duurtesten is al gebleken dat SSDs het veel langer dan deze specificatie kunnen volhouden, tot wel meerdere keren, maar dat valt uiteraard buiten de 'officiële gegarandeerde levensduur'.
Paar van deze SSD duurtests:Webarchive mirror mét afbeeldingen van de techreport review:Maar ook die officiële levensduur zegt nogal weinig zoals Elcomsoft heeft onderzocht:
Elcomsoft.com - Why SSDs Die a Sudden Death (and How to Deal with It)Why SSD Drives Fail with no SMART Errors
SSD drives are designed to sustain multiple overwrites of its entire capacity. Manufacturers warrant their drives for hundreds or even thousands complete overwrites. The Total Bytes Written (TBE) parameter grows with each generation, yet we’ve seen multiple SSD drives fail significantly sooner than expected. We’ve seen SSD drives fail with as much as 99% of their rated lifespan remaining, with clean SMART attributes. This would be difficult to attribute to manufacturing defects or bad NAND flash as those typically account for around 2% of devices. Manufacturing defects aside, why can an SSD fail prematurely with clean SMART attributes?
Each SSD drive has a dedicated system area. The system area contains SSD firmware (the microcode to boot the controller) and system structures. The size of the system area is in the range of 4 to 12 GB. In this area, the SSD controller stores system structures called “modules”. Modules contain essential data such as translation tables, parts of microcode that deal with the media encryption key, SMART attributes and so on.
If you have read our previous article, you are aware of the fact that SSD drives actively remap addresses of logical blocks, pointing the same logical address to various physical NAND cells in order to level wear and boost write speeds. Unfortunately, in most (all?) SSD drives the physical location of the system area must remain constant. It cannot be remapped; wear leveling is not applicable to at least some modules in the system area. This in turn means that a constant flow of individual write operations, each modifying the content of the translation table, will write into the same physical NAND cells over and over again. This is exactly why we are not fully convinced by endurance tests such as those performed by 3DNews. Such tests rely on a stream of data being written onto the SSD drive in a constant flow, which loads the SSD drive in unrealistic manner. On the other side of the spectrum are users whose SSD drives are exposed to frequent small write operations (sometimes several hundred operations per second). In this mode, there is very little data actually written onto the SSD drive (and thus very modest TBW values). However, system areas are stressed severely being constantly overwritten.
Such usage scenarios will cause premature wear on the system area without any meaningful indication in any SMART parameters. As a result, a perfectly healthy SSD with 98-99% of remaining lifespan can suddenly disappear from the system. At this point, the SSD controller cannot perform successful ECC corrections of essential information stored in the system area. The SSD disappears from the computer’s BIOS or appears as empty/uninitialized/unformatted media.
If the SSD drive does not appear in the computer’s BIOS, it may mean its controller is in a bootloop. Internally, the following cyclic process occurs. The controller attempts to load microcode from NAND chips into the controller’s RAM; an error occurs; the controller retries; an error occurs; etc.
However, the most frequent point of failure are errors in the translation module that maps physical blocks to logical addresses. If this error occurs, the SSD will be recognized as a device in the computer’s BIOS. However, the user will be unable to access information; the SSD will appear as uninitialized (raw) media, or will advertise a significantly smaller storage capacity (e.g. 2MB instead of the real capacity of 960GB). At this point, it is impossible to recover data using any methods available at home (e.g. the many undelete/data recovery tools).
Wat er dus erop neerkomt dat als de system-area van de SSD dusdanig versleten is, wat je niet kan herleiden uit het percentage die deze tools kunnen uitlezen, de SSD alsnog kapot kan gaan. Meestal worden ze read-only als je zoveel geschreven heeft zodat je de data er nog vanaf kan halen, maar de situaties die ik tot dusver heb gezien is dat ze eerst veel fouten genereren in de sectoren, vastlopen, vertragen, tot ze helemaal niet meer herkenbaar zijn in de bios en is het einde oefening.
Dat gebeurde overigens ook met een paar Samsung 850 Pro's in een vriend zijn X99 systeem, ondanks dat ze maar weinig of zelfs erg weinig schrijfacties hadden, maar wel veel uren gedraaid hadden. Was ook vrij kort na elkaar einde oefening.
Hier overigens een overzichtje van een paar SSDs die ik gebruik:
Wat ik jammer vind is dat CrystalDiskInfo geen historische statistieken kan inzien van verschillende storage media, zoals HD Tune Drive Status dit wel kan: