SSD betrouwbaarheid

Door CiPHER op vrijdag 7 juni 2013 10:34 - Reacties (22)
Categorie: SSD, Views: 31.077

Inleiding
Mijn tweede blog zal gaan over SSD betrouwbaarheid; of eigenlijk moet ik zeggen de gebreken op dit vlak.

Zoals in mijn vorige blogpost over SSD performance valt te lezen, ben ik van mening dat menig consument zich niet zo moet blindstaren op prestatieverschillen tussen SSDs. Vooral omdat die verschillen er niet zo toe doen; je merkt er nauwelijks wat van. Elke moderne SSD is een grote stap als je van een hardeschijf komt. Prestatieverschillen tussen moderne SSDs onderling zijn echter nauwelijks merkbaar.

Als verschillen op het gebied van prestaties er niet toe doen, worden andere verschillen veel belangrijker. En behalve prijs gaat het dan met name over de betrouwbaarheid van een SSD. Vreemd genoeg lijkt bijna niemand zich druk te maken over betrouwbaarheid. Jammer, want juist bij SSDs is dit het gebied waar de heren zich onderscheiden van de mannen.

Maar waar moet je dan op letten? Hoe moet jij nou weten welke SSD betrouwbaarheid is? Daarvoor lees je natuurlijk mijn blog! Dan kun je als consument gewapend met onafhankelijke kennis op pad; immuun voor alle deceptie die de leveranciers graag marketing noemen.

Voor diegenen met weinig tijd, snel doorklikken naar:
Wat is betrouwbaarheid?
Hier moet ik echt mee beginnen, want zo vreemd als het klinkt weet niet iedereen hierin de nuance aan te brengen. Dit werd duidelijk in mijn vorige blogpost, waar in de reacties onduidelijkheid bestond over het verschil tussen write endurance en betrouwbaarheid.

Laat ik betrouwbaarheid omschrijven als het zonder merkbare storingen blijven functioneren van het opslagapparaat, gedurende zijn levensduur. Je kunt dit omschrijven als betrouwbaarheid van een specifiek exemplaar - dus één sample - of in het algemeen over een productserie met heel veel samples. Dat laatste is tricky, want als iets als héél betrouwbaar te boek staat kan het nog steeds voorkomen dat jouw exemplaar de uitzondering is. En omgekeerd ook, SSDs die meer dan 50% failure rate hebben, kunnen bij anderen correct functioneren zonder dat zij problemen hebben ondervonden.

Betrouwbaarheid kun je wel onderscheiden in diverse aspecten:
  • Het niet zomaar defect raken van het apparaat gedurende de nominale levensduur, waarbij het apparaat ophoudt te functioneren, zoals niet meer herkend worden door de BIOS.
  • Het probleemloos functioneren van het apparaat, zonder timeouts, bad sectors, datacorruptie en andere tekortkomingen die te wijten zijn aan het opslagapparaat zelf.
  • Het hebben van een lange voorspelbare levensduur - de write endurance in geval van SSDs. Dit is een voorspelbaar gegeven afhankelijk van de SSD zelf en de wijze van gebruik; hoe snel je een apparaat slijt. Een goede analogie is een gloeilamp die een voorspelbaar aantal branduren heeft, of bijvoorbeeld een kaars. Dit is duidelijk verschillend van het punten hierboven, waarbij het juist gaat om onvoorspelbare levensduur.
  • Voorzieningen die tekortkomingen van het opslagapparaat zelf te adresseren, zoals een beveiliging voor de DRAM-writeback en interne werking van de SSD, zoals power-safe capacitors. Dit is deels overlappend met het 1e en 2e punt hierboven genoemd.
  • Voorzieningen die tekortkomingen van de host te adresseren. Een goed voorbeeld hiervan is TLER. Dit is niet nodig als de host goed met het apparaat omgaat, maar wel nodig om tekortkomingen in specifieke implementaties - voornamelijk hardware RAID - te adresseren. Eigenlijk een workaround voor een design flaw dus.
Bij veel discussies over writecycli wordt de betrouwbaarheid volkomen genegeerd. De enige vraag die men stelt is na hoeveel write cycli de SSD er totaal mee ophoudt. Maar die vraag is eigenlijk helemaal niet interessant. Veel interessanter is echter of de SSD bij normaal gebruik betrouwbaar blijft functioneren.


Annual Failure Rate
De meest universele expressie van betrouwbaarheid is de AFR wat in normaal Nederlands de jaarlijkse kans op falen inhoudt. Een AFR van 3% betekent dus dat als je tienduizend exemplaren gaat testen over een periode van 5 jaar, hier gemiddeld 15% van de exemplaren het einde van het 5e jaar niet halen. Dit betekent overigens niet dat de failures gelijkmatig zijn verdeeld over die 5 jaar; vooral bij hardeschijven zit hier veel verschil in waarbij de eerste jaren een lagere failure rate geldt terwijl die na het 3e jaar sterk kan oplopen. Er zijn diverse studies gedaan die dit patroon onderschrijven. Bij SSDs lijken de failures zich veel gelijkmatiger te spreiden over de jaren heen, wat betekent dat de kans op een defecte SSDs binnen enkele maanden na aanschaf relatief groter is dan bij een hardeschijf, maar uiteindelijk de hardeschijf het zal afleggen. De oorzaak hiervan kan heel divers zijn, maar naar mijn inschatting is het mechanische karakter van de hardeschijf hier debet aan. De SSD is solid state en als deze defect raakt is daar een oorzaak aan die anders is dan natuurlijke degradatie van fysieke componenten.

http://tweakers.net/ext/f/8FSMRkidOL2S8WJ1BH2YrTyh/full.jpg
AFR zoals opgegeven door Intel voor de Intel X25-M SSD


Wat is een failure?
Bedenk wel dat een failure in dit verband een niet heel duidelijk gedefinieerd begrip is. Volgens sommigen omvat dit alle defecten die de correcte werking verstoren. Dit betekent overigens niet dat een hardeschijf met bad sectors gelijk een failure is; technisch gesproken zijn deze ontworpen om bad sectors te genereren. Dit is vastgelegd in de uBER-specificatie. Een failure in dit verband betekent dat het niveau van bad sectors of andere oorzaken die die de normale werking verstoren, de opgegeven specificaties overstijgen. Kortom, als er meer bad sectors zijn dan zou mogen, dan is het een failure.

Maar anderen hanteren een striktere definitie van failure, waarbij het apparaat permanent defect dient te zijn. Bij hardeschijven betekent dit bijvoorbeeld niet meer opspinnen of niet gedetecteerd worden. Bij SSDs betekent dit dat ook na een secure erase-procedure de SSD niet meer tot leven komt.

Zelf denk ik dat de eerste definitie het beste is. Zo lang dat een apparaat binnen zijn specificaties opereert, is het niet defect. Als de specificaties zeggen dat tienduizend bad sectors normaal is - simpel gezegd - dan is het apparaat niet defect zolang het nog werkt en deze grens niet overschrijdt. Immers, je wist waar het product voor gespecificeerd cq. gecertificeerd was. De aanname hierbij is dat je rekening kunt houden met waar het product voor ontworpen is.


Write endurance
Dan belanden we bij de expressie van betrouwbaarheid waar veel consumenten zich druk over maken. Onterecht eigenlijk, want het zijn juist zakelijke gebruikers waarbij endurance oftewel duurzaamheid van belang is.

Een kleine opfrisser: SSDs kunnen vrijwel oneindig worden gelezen, maar hebben een beperkt aantal wis- en schrijfbewerkingen. Als je je SSD dus hoofdzakelijk gebruikt om van te lezen, kan deze absurd lang meegaan. Maar als je heel intensief gegevens schrijft naar de SSD, kan deze ook zeer snel onbruikbaar worden. Belangrijk hierbij is hoe de SSD gebruikt wordt, daarom kijken we specifiek naar:

Typisch consumentengebruik
Consumenten gebruiken een SSD eigenlijk op lichte manier. Dat wil zeggen dat de SSD maar zelden op volle snelheid wordt gebruikt. De keren dat een SSD op zijn snelst moet werken, is hoofdzakelijk als deze wordt gebenchmarkt. Bij normaal gebruik hoeft een SSD maar zeer zelden veel gegevens te schrijven. Denk aan installatie of updaten van software en kopieeracties. Maar daar houdt het dan wel bij op. Zeker een kleine SSD die als systeemschijf gebruikt wordt, zou maar minimaal belast moeten worden met writes. Als je zuinig bent met je SSD, kan deze dus decennia lang meegaan. Theoretisch zelfs meer dan 100 jaar.

Power-users of gebruikers met een grote SSD die niet alleen als systeemschijf wordt gebruikt, maar ook voor het downloaden en verwerken van grote bestanden, zullen hun SSD zwaarder belasten. Maar daarbij spelen twee verzachtende factoren: een grotere SSD kan automatisch ook meer schrijfacties verwerken. Normaliter betekent een dubbel zo grote SSD ook een dubbel zo grote write-endurance. Kortom, een 240GB SSD kan twee keer zoveel writes verwerken als een 120GB SSD. Daarnaast geldt dat het schrijven van grote bestanden minder belastend is dan zogenaamde random writes. Dit heeft te maken met de Write Amplification factor (WAf) - wat grofweg betekent dat het schrijven van 100GB ervoor zorgt dat een SSD intern tot 150GB moet verwerken. In dit voorbeeld is de WA-factor 1.50.

Typisch zakelijk gebruik
Bij zakelijke klanten gaat het veelal om serversystemen die zwaar belast worden en 24/7 hun werk doen. Denk aan webservers, databases, verwerking van betalingstransacties en klantbeheersystemen. De eigenaars van dergelijke servers willen natuurlijk een betrouwbaar product, maar als het product betrouwbaar werkt voor slechts 3 maanden lang, dan betekent dit wel een hoge kostenpot. Zie het als een kaars: hij kan betrouwbaar branden, maar wel snel 'op' zijn. Daarbij doel ik op de maximale writecycles waarvoor een SSD gespecificeerd is.

Voor zakelijke gebruikers is write endurance vooral een geldkwestie. Het kost geld om elke x maanden de SSDs te vervangen voor nieuwe exemplaren omdat ze hun opgegeven write cycles hebben overschreden. Niet alleen de kosten van de SSDs zelf - die doorgaans veel duurder zijn dan consumenten SSDs - maar vooral ook het offline halen van de servers en arbeidskosten die hierbij komen kijken. Minder vaak hoeven te vervangen betekent dus minder kosten.

Belangrijk is dat zakelijk gebruik zich kenmerkt door een veel zwaardere belasting in termen van absolute writes, maar ook in termen van het soort writes. Serversystemen zullen vaker dan bij consumentengebruik zogenaamde random writes uitvoeren, dit zijn kleine writes die een zwaardere belasting opleveren voor de SSD. Technisch gesproken betekent dit dat de WA-factor sterk zal stijgen. Dit betekent dat bij intensief gebruik in servers de SSD veel sneller door zijn writes zal gaan. Oftewel: de kaars brandt sneller op.

Omdat zakelijke gebruikers behoefte hebben aan hogere write endurance, kiezen zij vaak voor andere SSD technologie. Hieronder valt het bekende SLC NAND-geheugen, maar sinds enige tijd ook het eMLC geheugen. Dit laatste onderscheidt zich van normaal MLC-geheugen op twee punten: het kan meer writes verwerken, maar dat gaat wel ten korte van de dataretentie, die soms nog maar 3 maanden kan worden gegarandeerd. Dit type geheugen is veel minder geschikt voor consumenten en ook duurder.

Write endurance is voorspelbaar
Zoals hierboven uitgelegd, is write endurance eigenlijk helemaal niet zo relevant als het om betrouwbaarheid gaat. Immers: het is zo voorspelbaar. Je hebt een gegarandeerd aantal writes en je kunt middels de SMART simpelweg uitlezen hoeveel endurance je nog te gaan hebt. Oftewel, hoeveel van de kaars je reeds hebt opgebrand. Door de tijdsduur hierbij te betrekken, kun je ook een schatting maken op welke datum je SSD door zijn gegarandeerde writes heen zal gaan, aangenomen dat je gebruikspatroon nauwelijks verandert.

http://tweakers.net/ext/f/uwJKYqnsNEzJWQL9JHxqEFDn/full.png
Voorbeeld van voorspelbare duurzaamheid met SSDLife


Write endurance in reviews
Zoals hierboven uitgelegd is write endurance voor consumenten eigenlijk het minst interessant. Toch wordt hier veel aandacht aan geschonken door consumenten maar ook reviewers. Met name testen die zouden moeten aantonen dat SSDs ook nog blijven functioneren lang nadat zij de opgegeven write endurance hebben overschreden, zijn populair. Cruciaal hierbij is om te vermelden dat de write endurance niet een kwestie is van absolute writes waarna het apparaat er geheel mee ophoudt. Het échte probleem is dat naarmate de geheugencellen door hun write cycles heenbranden, de betrouwbaarheid sterk afneemt. Dit aspect wordt veelal niet vermeld bij de testen die dergelijke reviews uitvoeren, terwijl dit toch een cruciaal punt is van zorg.

De write endurance is derhalve niet een kwestie van absoluut aantal write cycles dat je opslagapparaat kan verwerken, maar meer een algemene grens waarbij je SSD betrouwbaar blijft functioneren gegeven een hoeveelheid writes. Naarmate je de opgegeven writecycles overschrijdt, zal de betrouwbaarheid namelijk sterk afnemen en neemt de kans op corruptie toe. Dit wordt enigszins gemaskeerd door de manier van testen, omdat de betreffende geheugencellen continu worden ververst met nieuwe gegevens die de retentietijd telkens resetten. Hierdoor blijft het probleem van verminderde betrouwbaarheid grotendeels gemaskeerd.

Dit leidt uiteindelijk tot verkeerde conclusies door lezers van dergelijke reviews. Zij zullen namelijk in de veronderstelling zijn dat write endurance een totaal non-issue is omdat je zelfs nog een werkend opslagapparaat hebt naarmate je de opgegeven writes met grote marge hebt overschreden. Echter, dat de SSD hierdoor flink inboet in termen van betrouwbaarheid, wordt niet altijd voldoende begrepen of uitgelegd in de reviews. In zijn algemeenheid kun je stellen dat je SSD het meest betrouwbaar is tot de helft van de opgegeven write endurance. Daarna loopt het gestaag af en na de opgegeven write endurance gaat de betrouwbaarheid hard achteruit. De kans op corruptie neemt dan sterk toe, met name bij realistisch gebruik waarbij de retentietijd niet continu gereset wordt en de SSD niet continu van stroom wordt voorzien.


Dataretentie
Vaak hopeloos genegeerd is de retentie van de opgeslagen data, oftewel de dataretentie. Dit houdt simpelweg in dat het opslagapparaat de opgeslagen gegevens slechts beperkte tijd kan behouden zonder deze opnieuw te schrijven. Retentie bij hardeschijven is een moeilijk begrip waar ik dieper op in zal gaan in de toekomstige blog over HDD betrouwbaarheid. In deze blog richt ik mij specifiek op SSDs en in dit verband is de retentie veel duidelijker, zij het vaak verkeerd begrepen of zelfs geheel onbekend bij het grote publiek.

Retentie bij consumenten SSDs
Normaliter hebben SSDs bedoeld voor consumenten een gegarandeerde retentieduur van tenminste 12 maanden. Dit is vastgelegd in JEDEC-specificatie JESD22-A117B die NAND-producenten hanteren om tot algemene standaardisering te komen. Die 12 maanden is dus een soort garantie dat 99%+ van de NAND cellen gedurende hun write endurance hun data blijven behouden.

Retentie bij enterprise SSDs
Heel anders dan de SSDs voor consumenten hebben zakelijke gebruikers er baat bij om wat retentie op te offeren in ruil voor extra writecycli ofwel write endurance. Aangezien de gebruikers van dergelijke enterprise SSDs weten dat het product een minder hoge retentietijd heeft van bijvoorbeeld 3 maanden, kunnen ze hier rekening mee houden. Zij zullen dergelijke vaak peperdure SSDs echt niet een half jaar op de plank laten liggen. In elk geval niet terwijl de gegevens nog nodig zijn. Enterprise-gebruikers hebben vaak hun backups goed geregeld en retentietijd is derhalve helemaal niet zo interessant. Voorts worden de gegevens veelal ook vaak bijgewerkt en dus overschreven, waardoor de benodigde retentietijd in sommige gevallen niet langer hoeft te zijn dan een week. Maar enige marge is altijd fijn, en drie maanden tijd is veruit voldoende voor het typische gebruik van enterprise SSDs.

Retentie loopt terug naarmate de SSD gebruikt is
Interessant om te vermelden is dat de retentietijd sterk afhangt van de mate van slijtage van de NAND cellen. Een SSD met 12 maanden gegarandeerde retentie, zal in de praktijk een gemiddelde retentie hebben van ongeveer 10 jaar wanneer de SSD nog vers en ongebruikt is. De retentie neemt af naarmate de SSD door zijn write cycles heengaat, waarbij 12 maanden retentie nog haalbaar zou moeten zijn - gemiddeld - wanneer de gegarandeerde writecycles zijn opgebruikt. Er zit hier echter wel een grote maar bij: de retentie is niet gelijkmatig verdeeld over alle NAND cellen. De ene cell zal sneller degraderen dan andere cellen. Gevolg is dat je gemiddelde retentie wel 12 maanden kan zijn, maar dat een handjevol cellen een sterk verminderde retentie kennen. Je wilt dus altijd een flinke marge hebben om dit effect te minimaliseren, vooral omdat je niet vooraf kunt meten welke cellen een lagere retentietijd hebben.

http://tweakers.net/ext/f/LK3x6lWvsPLcaaa5smCrNfOL/full.gif
De retentie loopt terug van 10 jaar tot 1 jaar vanaf 10% van de opgegeven write endurance


Retentie loopt terug wanneer de SSD onverwacht stroom verliest
Als een SSD onverwacht stroom verliest en deze beschikt niet over power-safe capacitors zoals hieronder beschreven, dan kunnen één of meerdere NAND pages permanent beschadigd worden. Dit valt niet of nauwelijks te meten of te detecteren en geldt zeer specifiek voor de pages waarvan de write-cycle is onderbroken door onverwacht stroomverlies. Deze pages zullen in veel gevallen permanent een lagere retentie krijgen dan gebruikelijk is voor het type NAND chip. Hier valt ook niets meer aan te doen. Zeker voor zakelijk gebruik is stroombeveiliging in de vorm van UPS maar vooral power-safe capacitors dus eigenlijk een absolute must. Equivalent hieraan is de ECC-bescherming voor RAM-geheugen, die eigenlijk ook niet optioneel is voor échte servers die gewoon absoluut betrouwbaarheid moeten functioneren. Met dergelijke serieuze eisen aan betrouwbaarheid dient de technologie ook over de juiste voorzieningen te beschikken om dit mogelijk te maken. Enterprise-gebruikers wantrouwen om deze reden veelal consumentenproducten, omdat deze vaak ontworpen zijn om nét betrouwbaar genoeg te zijn voor consumentenbegrippen, maar zeker niet voldoen aan de eisen die zakelijke gebruikers stellen. Maar er zijn uitzonderingen, zoals we straks zullen zien.

Retentie kan worden gemanaged door de controller
Om het verhaal nóg iets complexer - maar daarmee ook vollediger - te maken, moet ik vermelden dat retentie kan worden gemanaged door de controllerchip. Dit betekent dat de controller kan weten welke cellen lange tijd niet ververst zijn en zodra er een grens wordt bereikt - de retention threshold - kan de controllerchip besluiten de gegevens opnieuw te schrijven. Het probleem hierbij is dat de controllerchip moet bijhouden welke cellen lange tijd onbeschreven zijn. Hier kunnen diverse mechanismen voor gebruikt worden, maar de mechanismen die echt effectief zijn, zijn erg complex en zul je naar alle waarschijnlijkheid niet terugvinden in consumenten SSDs. De meest simpele implementatie is de tijd meten hoelang de SSD voor het laatst van stroom is voorzien. Als deze tijd te lang is, zal er een verversing plaatsvinden van alle NAND cellen die host-data bevatten. De complexe implementaties zullen een tabel bijhouden naast de mapping tables die bijhouden hoe lang geleden deze beschreven zijn, en dynamisch de data verversen wanneer nodig. Het is mij niet bekend welke producten welke implementaties gebruiken. Ik denk dat je moet aannemen dat consumenten SSDs geen afdoende bescherming hebben in dit opzicht. Ze zullen simpelweg vertrouwen op de relatief hoge retentietijd die de reguliere NAND-chips van nature hebben.

Retentie wordt getest in de oven
Geen grapje! De JEDEC - een onafhankelijke organisatie voor standaardisering in de halfgeleidersindustrie - gebruikt methoden van verhitting om de retentietijd de voorspellen. Het is namelijk ondoenlijk om een product 10 jaar lang uit te testen op retentie voordat het op de markt wordt gebracht. In plaats daarvan worden geheugenchips in de oven geplaatst ter certificatie. Daarbij geldt dat 24 uur in een oven van 250 °C overeenkomt met een duur van 1000 jaar bij 25 °C. Dit is echter louter een wiskundige formule die wel ongeveer zal kloppen, maar waar ik altijd redelijk skeptisch over ben. Ik vraag mij namelijk af of je na 1000 jaar bij 25 graden Celsius wel degelijk in de praktijk overeenkomt met die 24 uur in de oven. Maar het is een standaard, tenminste iets waarop je de retentietijd kunt testen. Beter iets dan niets. Maar neem het wat mij betreft met een korrel zout. Niemand die over 1000 jaar gaat klagen dat de retentietijd niet klopt met wat de JEDEC destijds heeft aanbevolen. Aangezien geld in zijn huidige vorm over een dergelijke periode ook niet meer zal bestaan, kun je je schadeclaim dus wel vergeten. ;)


Hardwarematige bescherming
Betrouwbaarheid begint met de hardware. Hardware wil zeggen dat je het kunt aanraken; dat het fysiek is. Een SSD is een fysiek apparaat, dus hardware. Maar de data die erop staat, valt binnen het softwarematige oftewel digitale domein. De data is afhankelijk van de kwaliteit van de hardware. Dit omvat de kwaliteit van de NAND chips, de controllerchip en de connectie naar de controller toe.

SSDs onderscheiden zich in de mate van hardwarematige voorzieningen die tot doel hebben om dataverlies te voorkomen. We kunnen hierbij onderscheiden:

Stroomvoorziening
SSDs op basis van NAND technologie zijn om meerdere redenen zeer kwetsbaar voor onverwacht stroomverlies. Voordat de SSD stroom mag verliezen, dient deze eerst een STANDBY IMMEDIATE commando te ontvangen van de host; een seintje dat zegt: hey bereid je maar voor want de stroom gaat er zo af. Iedere keer dat een SSD stroom verliest zonder dat dit commando eraan voorafging, telt als een Unexpected Power-Loss. Dit kun je voor de betere SSDs ook terugvinden in de SMART-informatie, die je met het programma CrystalDiskInfo kunt uitlezen.

Onverwacht stroomverlies gebeurt veel vaker dan veelal wordt aangenomen. Veel mensen denken namelijk dat dit enkel gebeurt als je een stroomstoring hebt thuis. Dit is echter niet correct; ook een blauw scherm/crash gevolgd door een power-cycle, of de stroomknop gebruiken terwijl je in het BIOS zit, telt als onverwacht stroomverlies. Ook kunnen er bugs zijn waardoor hibernation, energiebesparingsfuncties en zelfs een nette shutdown als onverwacht stroomverlies zal tellen. Onder andere Windows heeft dergelijke bugs gekend, wat ervoor zorgde dat iedere shutdown telde als een unclean shutdown. Dan is het eigenlijk meer een kwestie van tijd dat het misgaat. Want iedere unclean shutdown is dobbelen in het casino. Als je maar lang genoeg dobbelt, krijg je een keer de hoofdprijs. En in dit geval is dat een corrupte SSD.

Power-safe capacitors
Om het risico van onverwacht stroomverlies in te dammen, worden de betere SSDs uitgerust met een beveiliging die bij onverwacht stroomverlies nog héél heel even stroom kunnen leveren. Dit is genoeg om de huidige write cycle af te maken en de mapping tables veilig af te sluiten. In de meeste gevallen gaat de write buffer wel verloren; dit zijn writes die de controller heeft ontvangen maar nog niet zijn weggeschreven. Echter, hier bieden filesystems afdoende bescherming voor in de vorm van intent logs, journalling en soft updates. Dit zou dus niet voor corruptie mogen zorgen, hooguit dat je de laatste x seconden kwijt bent; alsof die nooit hebben plaatsgevonden.

Er zijn twee vormen van power-safe capacitors:
  • Supercapacitor
  • Array of capacitors
Het verschil is simpel: de supercapacitor is één hele grote capacitor en de array of capacitors is een batterij van kleinere capacitors. De term supercapacitor wordt vaak gebruikt voor dit type beveiliging, maar tegenwoordig wordt vooral de array of capacitors geïmplementeerd in moderne SSDs. Dit omdat een supercapacitor stuk kan gaan en de bescherming dan niet meer werkt, terwijl bij de batterij van kleinere capacitors er één of twee capacitors stuk mogen gaan terwijl de bescherming dan nog intact blijft. Er zit namelijk een marge in de hoeveelheid stroom die nodig is en die de capacitors kunnen leveren.

http://tweakers.net/ext/f/3nsg1vL4mBrKCvpeYzjQAQCB/medium.jpghttp://tweakers.net/ext/f/l0w1P70Z0o42mlu5vejylz9k/medium.jpg
SupercapacitorArray of capacitors


Interessant om te vermelden in dit verband is dat het simpelweg aanbrengen van wat capacitors niet voldoende is. De firmware - de software - moet deze ook op de juiste wijze benutten. De eerste consumenten SSD met deze beveiliging - de Intel 320 - liet het op dit punt afweten. De firmware werkte niet goed samen met de capacitors, met als gevolg dat er alsnog een stroomonderbreking plaatsvond op het verkeerde moment. Dit is bekend komen te staan als de 8MB bug. Echter, deze benaming is misleidend. De 8MB bug was eerder het gevolg van onverwacht stroomfalen doordat de power-safe capacitorbeveiliging niet correct functioneerde door een firmwarebug. Doordat de beveiliging niet goed werkte, kon er alsnog corruptie plaatsvinden in de mapping tables - die tabellen houden bij hoe en waar je data is opgeslagen en zijn cruciaal voor het functioneren van een SSD. Als die corrupt raken, kan de firmware van de SSD heel divers reageren. Sommige SSDs zullen niet langer herkend worden door het BIOS, anderen zullen totale corruptie over het gehele oppervlak tonen, terwijl Intel de eigenschap had dat bij corrupte tabellen de SSD als 8MB groot werd herkend; vandaar de naam '8MB bug'.

Dit werd door veel consumenten opgevat als dat de Intel 320 minder betrouwbaar was. De ironie is echter, dat juist alle andere SSDs een '8MB bug' hebben, omdat deze sowieso geen power-safe capacitorbescherming hebben en dus altijd corrupt kunnen raken bij stroomverlies op het verkeerde moment. De Intel 320 had deze bescherming wel als enige moderne consumenten SSDs destijds. Dat deze in het begin niet goed functioneerde - iets wat Intel oploste met een firmwareupdate - doet daar niets aan af. Kortom, alle SSDs hebben de 8MB bug, terwijl een Intel 320 met geüpdated firmware deze bug juist niet heeft. Best wel ironisch dat de Intel 320 dan altijd in verband wordt gebracht met de '8MB bug'. ;)

DRAM write-back
Een ander hardwarematig punt is de aanwezigheid van de DRAM geheugenchip, vaak vlak naast de controllerchip gehuisvest. Deze geheugenchip, die je ook op RAM-geheugenmodules kunt terugvinden, wordt gebruikt om de controllerchip te ondersteunen in zijn taak en is vooral van belang voor het opkrikken van de prestaties. Echter, er zijn twee manieren waarop de chip gebruikt kan worden:
  • Cachen van de mapping tables - de FTL
  • Bufferen van schrijfbewerkingen; write-back buffering
Het eerste is de meest belangrijke; de DRAM-chip is veel sneller dan de NAND chips qua latency (vertraging) en kan dus veel beter dienen om de controllerchip te ondersteunen wanneer het de mapping tables moet raadplegen, wat minimaal eens het geval is bij elke I/O-bewerking en soms zelfs meerdere keren per bewerking. Ook kunnen wijzigingen aan de tabellen zo worden gebuffered, zodat niet voor iedere schrijfbewerking de tabellen naar NAND hoeven worden weggeschreven.

Sommige SSDs gebruiken de DRAM chip enkel voor het cachen en bufferen van de mapping tables. De Intel 320 is hiervan het beste voorbeeld; de DRAM-chip wordt niet gebruikt voor schrijfacties. In plaats daarvan heeft de controllerchip een 256KiB grote SRAM buffercache om de writes tijdelijk in te kunnen opslaan. Dit SRAM-geheugen is gelijk aan de Level1 en Level2 SRAM-cache zoals aanwezig in moderne Intel en AMD-processors en is sneller en betrouwbaarder dan DRAM geheugen, maar ook vele malen duurder dan DRAM.

Helaas is het erg verleidelijk om niet te investeren in SRAM maar de DRAM-chip te gebruiken voor het bufferen van schrijfbewerkingen. Dit betekent dat de schrijfbewerkingen simpelweg verdwijnen zodra de stroom onaangekondigd wegvallen. Ook is het een extra risico aangezien de data een omweg neemt waarbij corruptie op de loer ligt.

http://tweakers.net/ext/f/E7voCrR866eilKVajX1nnn4E/full.png
Midden: Samsung controller; onder: DRAM-chip; rechts: NAND-geheugenchips


End-to-end data integrity
Met name op het gebied van datacorruptie is de end-to-end data integrity het vermelden waard. Want zoals velen weten kunnen DRAM-chips corruptie vertonen en dit heeft de potentie om al je data te corrumperen zonder dat dit opgemerkt wordt. Je NAND kan dan heel betrouwbaar zijn evenals je controllerchip, maar als de DRAM-chip als buffer wordt gebruikt voor de schrijfbewerkingen en deze vertoont corruptie, dan heb je een groot probleem. Om dit enigszins te verzachten, is er het principe van end-to-end data integrity. Dit heeft tot doel om de data van bron tot eindbestemming te volgen en de integriteit ervan te bewaken. Anders gezegd: zodra de SSD de gegevens in handen heeft, garandeert het dat de gegevens ervan niet gecorrumpeerd worden. Ofwel het kan de gegevens niet meer leveren en het stuurt een I/O-error terug, ofwel het stuurt de gegevens terug zoals deze origineel door de SSD zijn ontvangen. Corruptie mag dus niet plaatsvinden, dat is een essentieel onderdeel van een betrouwbaar opslagapparaat.

In veel implementaties van end-to-end data integrity wordt ECC ofwel pariteitsbescherming toegevoegd om corruptie op te merken. Indien er corruptie heeft plaatsgevonden die niet te corrigeren is, zal de I/O-bewerking opnieuw plaatsvinden. In de SMART-gegevens kan men vaak aflezen hoe vaak dit gebeurt. Een slechte score op het gebied van end-to-end data integrity betekent vaak dat de DRAM-chip defect is en corruptie vertoont. Het apparaat wordt hierdoor minder betrouwbaar, maar blijft veelal wel functioneren.


Softwarematige bescherming
Zoals het verhaal hierboven met de Intel 320 al duidelijk maakt, zijn hardwarematige beveiligingen nog geen garantie dat alles goed werkt. De mogelijkheden die de hardware biedt, moeten ook door de software op juiste wijze worden benut. De software in dit verband is de firmware die de controllerchip aanstuurt. Deze firmware is niet zomaar uitwisselbaar met andere SSDs; dergelijke firmware is heel specifiek voor een controllerchip geschreven. Maar de firmware is doorgaans wel te updaten, wat nodig kan zijn om bepaalde bugs te verhelpen. En dat is enorm vaak voorgekomen in de historie van moderne SSDs vanaf de 2e generatie. Er zijn eigenlijk geen uitzonderingen: alle controllerchips hebben firmwarebugs gekend die tot dataverlies konden leiden. Sommigen waren minder ernstig, zoals de Intel X25-M G2 een datalossbug had die enkel optrad als je een BIOS HDD wachtwoord instelde en ook TRIM gebruikte. Dit deden niet veel mensen, en ik kan me voorstellen dat zoiets door de certificatie komt omdat een BIOS wachtwoord niet zovaak wordt gebruikt laat staan getest.

Toch is het belangrijk om stil te staan hoe complex een moderne SSD eigenlijk is. Dat is ook de grootste reden dat SSDs zoveel gebreken kennen die hun betrouwbaarheid aantasten. De SSD is eigenlijk een kleine computer met een processor, met geheugen, met een operating system (de firmware) die uiteindelijk de NAND-chips aansturen. Waarom zoveel complexiteit? Dat is iets wat ik in een volgende blog zal behandelen. De korte conclusie is dat dergelijke complexiteit nodig is omdat zonder die complexiteit SSDs heel traag zouden zijn met random writes. USB-sticks zijn hier een goed voorbeeld van. Sommige USB-sticks zijn een factor 100 tot 1000 trager dan een 5400rpm hardeschijf op het gebied van random write. Een moderne SSD is een factor 100 sneller dan een dergelijke schijf; dus je zit aan een factor 100.000 verschil. Aha, nu snap je waarom die compexiteit nodig is. ;)

Laten we kijken naar welke softwarematige voorzieningen we kunnen onderscheiden als het gaat om betrouwbaarheid:

ECC
De basis van gegevensbescherming begint met errorcorrectie. De meest bekende en meest toegepaste vorm hiervan is ECC; Error Correcting Code. Dit is een vorm van errorcorrectie, terwijl het eveneens bekende CRC een vorm van errordetectie is. Het verschil mag duidelijk zijn: waar CRC enkel fouten kan detecteren, kan ECC deze ook corrigeren. De ECC errorcorrectie wordt toegepast binnen NAND pages; dit zijn blokjes van 4K of 8K waar een vorm van ECC is toegepast. Technisch gesproken heet dit de spare area - wat niet verward mag worden met de spare space die SSDs veelal hebben om hun prestaties op peil te houden. De spare area is een extra opslaggebied van een NAND page die errorcorrectie kan worden gebruikt. Als we aannemen een NAND page van 2KiB groot, dan is deze niet 2048 bytes zoals je zou verwachten, maar in werkelijk is deze 2048+64 = 2112 bytes groot.

http://tweakers.net/ext/f/UBge2HHm2SEaUBJpUhQcMsuK/full.png
NAND page van 2KiB met 64 bytes aan spare area


ECC overhead
Hedendaags zijn de NAND pages groter geworden omdat dit voordelen kent op het gebied van prestaties en gemakkelijker is om bij te houden; minder blocks betekent minder overhead. De huidige page size is om die reden 8KiB bij de huidige generatie SSDs. Dit betekent overigens niet dat de ruimte voor foutcorrectie in gelijke grootte dient toe te nemen. Met grote blocks is relatief minder foutcorrectie nodig:

http://tweakers.net/ext/f/aSiu1nfePVjo7v3jWZXdYulp/full.png
Grotere blocks betekent relatief minder ECC-overhead


RAID5 bitcorrectie
Naast ECC is een belangrijke vorm van foutcorrectie de toepassing van pariteit. Dit is beter bekend als RAID5. Zoals in de vorige blog over SSD performance reeds is opgemerkt, zijn SSDs in feite RAID-controllers die meerdere NAND-chips in RAID0 aanspreken voor extra performance. Maar moderne SSD controllerchips gebruiken echter geen RAID0 maar gebruiken ofwel RAID4 (Intel) of RAID5 (Marvell, Sandforce). Dit betekent dat er naast ECC nog een extra laag aanwezig is die fouten kan corrigeren.

http://tweakers.net/ext/f/eIK4rLleuLFmh7EVbcQSD5tG/full.png
RAISE foutcorrectie gebruikmakende van pariteit zoals gebruikt in Sandforce controllers


Meer bitcorrectie nodig naarmate NAND-chips kleiner worden
Het effect van dergelijke pariteitscorrectie is dat de uncorrectable Bit-Error Rate oftewel de uBER nog verder wordt verkleind. Helaas voor ons consumenten wordt dergelijke bescherming in het huidige tijdperk veelal gebruikt als compensatie voor ECC, zodat in werkelijkheid de betrouwbaarheid niet zo hoog is als zou kunnen en zoals in het bovenstaande plaatje wordt gesuggereerd. Dit komt omdat naarmate de NAND-geheugenchips kleiner worden, er meer foutcorrectie nodig is. De overhead die hierdoor nodig is, stijgt steeds sneller naarmate de chips kleiner worden en de datadichtheid toeneemt:

http://tweakers.net/ext/f/slQSRu7oa0npuE9LF05b0Bqx/full.jpg
De noodzaak voor errorcorrectie neemt toe naarmate de NAND-chips kleiner worden


Errorcorrectie is dynamisch aan te passen
Belangrijk om te weten is dat errorcorrectie een dynamisch iets is. Daarme bedoel ik dat betrouwbaarheid simpelweg een afweging is tussen overhead (benodigde rekenkracht en opslagruimte) en bruikbare opslagruimte. Het is gemakkelijk om een veel betrouwbaardere SSD te maken die simpelweg meer ruimte ter beschikking stelt aan foutcorrectie. Dat betekent wel een verhoging van de benodigde rekenkracht en daarmee een daling van de prestaties. Tevens is er minder ruimte beschikbaar voor het behouden van dataretentie of bruikbare opslagruimte als de ruimte voor foutcorrectie wordt vergroot. Kortom, het zijn afwegingen. Het is een soort van slider. Je kunt de foutcorrectie dynamisch aanpassen als je toegang zou krijgen tot de firmware. Mijns inziens zou het wenselijk zijn om de foutcorrectie een flinke boost te geven, om opslagappraten in de buurt van uBER=10^-29 te krijgen zoals het plaatje hierboven van Sandforce doet suggereren. Dat zou werkelijk fantastisch zijn omdat je dan een geweldige marge van foutcorrectie hebt en daarmee de betrouwbaarheid naar een hoger niveau tilt. Maar in wiens belang is het? Niet in het belang van de fabrikant, die wil zijn apparaat tegen een zo'n lage prijs verkopen en tegen zulk hoge specificaties als maar mogelijk is. Kortom, er is hier sprake van tegengestelde belangen, zoals zo vaak in de wereld van het kapitalisme.

http://tweakers.net/ext/f/xvCQH22Jfb8G2oywbHJPp2vn/full.jpg
uBER en BER is een kwestie van afwegen tussen betrouwbaarheid en overhead


Firmwarebugs
Ten slot de firmware zelf. Dit is in feite software die de ARM-processorchip bestuurt en het NAND-geheugen aanstuurt om uiteindelijk aan de host een werkend opslagapparaat te presenteren. De firmware is waar alle magie plaatsvindt. De betrouwbaarheid van een SSD hangt dan ook voornamelijk af van de firmware. Echter, de firmware kan enkel magie gebruiken voor zover de hardware toelaat. De hardware is de ultieme bottleneck, de firmware oftewel de software is de mate waarin de potentie van de hardware wordt benut. Dit geldt zowel voor de prestaties als voor de betrouwbaarheid.

Bekend is dat de Crucial M4 een firmware-update kreeg die zijn prestaties opkrikte van 400MB/s sequential read naar 500MB/s sequential read. Dit is de merkbare invloed van firmware op de prestaties. Maar evengoed merkbaar is de invloed van firmware op de betrouwbaarheid. Het is namelijk geen geheim dat SSD firmwareupdates cruciaal zijn voor het oplossen van bugs. Bugs met soms heel vervelende gevolgen, zoals verlies van gegevens of het belemmeren van de normale werking, zoals bij de 5000-urenbug van de Crucial M4.

Belangrijk om te weten is dat vrijwel alle fabrikanten inclusief Intel te maken hebben gehad met ernstige firmwarebugs die dataverlies konden veroorzaken. Er zijn uitschieters in negatieve zin zoals Sandforce die als brokkenpiloot bekend staat, maar positieve uitschieters zijn er nauwelijks. Het meest betrouwbaar in termen van firmware zijn Intel en Samsung, die de minste firmwarebugs hebben die dataverlies konden veroorzaken. Maar zoals gezegd; iedereen is aan de beurt geweest. Laat dit een waarschuwing zijn voor de relatieve kwetsbaarheid van SSDs voor firmwaredefecten. Mijns inziens is dit het gevolg van de hoge mate van complexiteit van moderne SSDs. Teneinde de prestaties op te krikken wordt er ingeleverd op betrouwbaarheid.


Hall of fame
Ere wie ere toekomt. Mijn lijst van de meest betrouwbare consumer-grade SSDs:

Eerste plaats: Intel 320 series
Tweede plaats: Crucial M500
Derde plaats: Seagate 600 Pro

De nummers twee en drie zijn nieuwkomers die zichzelf nog moeten bewijzen. Echter, deze drie zijn wel de enige moderne SSDs die inherent veilig zijn door de aanwezigheid van hardwarematige voorzieningen zoals RAID-bitcorrectie en power-safe capacitors. Aangenomen dat de firmware het niet laat afweten in de vorm van verborgen firmwarebugs, hebben deze SSDs dus alle potentie om heel betrouwbaar te zijn. Nog steeds niet zo betrouwbaar als eigenlijk zou moeten; 0.5% AFR vind ik nog steeds te hoog. Maar dergelijke cijfers zijn lager dan die van hardeschijven (0,7 - 3,0%).


Hall of shame
Eigenlijk zouden de fabrikanten van alle SSDs die een hogere annual failure rate (AFR) hebben dan 0,5% zich moeten schamen. Vooral omdat een SSD zoveel potentie heeft om betrouwbaar te zijn. Dat er SSDs zijn die ogenschijnlijk hier ver bovenuit schieten is dan ook ronduit schandalig. Dus een Hall of Shame is denk ik wel gerechtvaardigd.

Slechtste SSD ooit: OCZ Octane 3Gbps (45 - 52% failure rate)
Tweede slechtste SSD: OCZ Petrol (41 - 45% failure rate)
Derde slechtste SSD: OCZ Agility 4 (7 - 10% failure rate)

http://tweakers.net/ext/f/nSiepTR9P4mr3Exyn2yOLNoM/full.png
OCZ: de experts op het gebied van failure rates!


OCZ moet zich schamen
De boodschap is duidelijk als je de failure statistieken moet geloven: OCZ is de leverancier van SSDs met veruit de hoogste failures rates. Niet alleen voor gemiddeld alle SSDs die het bedrijf levert, maar ook voor specifieke series die de lijst van de minst betrouwbare SSDs aanvoeren. Dit valt een bedrijf als OCZ natuurlijk zeer aan te rekenen, vooral omdat dit merk zeer succesvol is gebleken met het binden van consumenten en het voeren van effectieve marketingstrategie. Zoveel consumenten die zo graag een mooie SSD wilden en hier voor hebben gespaard of deze kado hebben gekregen, hebben veel ellende en verdriet gehad van de enorme problemen waar zij mee kampten. Zoals nu blijkt uit diverse bronnen van failure statistieken, is het zeker geen overdrijving dat OCZ veel vaker dan andere merken het laat afweten. Failure rates van boven de 50% zijn bijna crimineel te noemen. Als je het zo slecht doet als bedrijf, verdien je het naar mijn oordeel om hier stevig op te worden aangesproken. Naming and shaming is dan ook mijn devies.

Desalniettemin moet ook worden gezegd dat zelfs een failure rate van boven de 50% betekent dat er ook consumenten zijn waarvan hun OCZ SSD goed functioneert. Met name de betere modellen (Vertex 3) doen het nog vrij aardig, ook al hebben zij ook te maken met hoger dan gebruikelijke failure rates.

Het is eigenlijk nóg erger
Belangrijk is wel om op te merken dat OCZ - anders dan andere fabrikanten - direct garantie afwikkelt met de eindgebruiker. Intel doet dit bijvoorbeeld niet en dat betekent dat alle failures via de officiële distributiekanalen verlopen. Dit maakt het vormen van betrouwbare failure statistieken ook makkelijker. OCZ en Samsung handelen echter direct met de consument als via distributiekanalen de garantieclaims af. Dit betekent dat naar alle waarschijnlijkheid de failure rates zoals gemeten door distributeurs nog veel hoger zijn. Ik speculeer hierbij dat OCZ dit wel moet doen, om te voorkomen dat hun distributeurs en retailers gek worden van de extreem hoge uitval. Door de garantie direct met de consument af te handelen, voorkomen ze dat de leveranciers het zat worden en stoppen met de import/verkoop van OCZ SSDs. Daarnaast maakt OCZ goede naam op het gebied van aftersales door laagdrempelige garantieafwikkeling aan te bieden via hun website, waar je op het forum heel gemakkelijk in contact kunt komen en al snel wordt verwezen naar de interne garantieafdeling van het bedrijf. Dit geeft consumenten al gauw een positieve indruk van de garantieafwikkeling, totdat zij hun geretourneerde SSD voor de derde maal stuk hebben zien gaan. Dan maken zij vaak geen gebruik meer van de laagdrempelige service maar kopen een SSD van een ander merk wat wél betrouwbaar functioneert.

Sterf!
Het is voor mij erg moeilijk om genuanceerd te blijven als het gaat om OCZ. Het is dan ook met groot genoegen dat ik lees over de financiële problemen, dreigend bankroet en een strafrechterlijk onderzoek naar dit bedrijf. Laten we hopen dat het 'tijdperk OCZ' zo snel mogelijk kan worden begraven en consumenten niet langer massaal worden benadeeld door dit bedrijf. Helaas voor ons weten de ratten het zinkende schip veelal op het laatste moment te verlaten en zichzelf in leven te houden.


Conclusie
De conclusie van het bovenstaande verhaal is dat SSDs niet alleen op prestatiegebied maar ook op gebied van betrouwbaarheid sterk afwijken van mechanische hardeschijven. Een SSD kan op veel verschillende manieren stuk gaan, terwijl een hardeschijf eigenlijk maar twee failure modes kent: bad sectors en mechanisch falen. SSDs zijn extra kwetsbaar door de fundamentele tekortkomingen van de huidige generatie SSDs op basis van NAND-flashgeheugen.

Tevens zijn de huidige generatie SSDs inherent onveilig. Ze zijn in feite gemaakt om defect te raken. Niet opzettelijk, maar desalniettemin is hun falen het gevolg van een gebrekkig ontwerp; de SSD heeft een window of opportunity waarin het corrupt kan raken als op dat moment de stroom onaangekondigd wegvalt. Dat is echter onnodig; er kunnen voldoende beveiligingen worden ingebouwd die de betrouwbaarheid van de SSD sterk vergroten.

Op dit moment zijn er slechts drie moderne consumenten SSDs die voldoende bescherming bieden, waarvan er twee relatief nieuw zijn op de markt en zich nog niet volledig hebben bewezen. Dat is belangrijk om te weten als potentiële koper van een SSD en derhalve zou betrouwbaarheid hét belangrijkste criterium kunnen zijn - en wat mij betreft ook moeten zijn. Prestatieverschillen merk je vrijwel niets van, maar gezeik met je SSD en niet meer kunnen opstarten of het opstarten duurt opeens 15 minuten; dat zijn zaken die je niet verwacht van een dure investering wat een SSD toch nog steeds is. Kortom, laat je aandacht uitgaan naar betrouwbaarheid. Daarmee vergroot je de kans dat je vele jaren plezier van je SSD zult beleven zonder problemen, frustratie en dataverlies. Gun jezelf een kwaliteits SSD voor een tientje extra!

Volgende: SSD best buy guide 06-'13 SSD best buy guide
Volgende: SSD performance 05-'13 SSD performance

Reacties


Door Tweakers user F.West98, zaterdag 8 juni 2013 01:08

Erg uitgebreide post weer, erg interessant!
Ik vroeg me af, hoe schat jij de betrouwbaarheid van de Samsung 830 en de Crucial m4 in? Goed betrouwbaar, voor licht gebruik zoals jij omschreef of niet?

Door Tweakers user CiPHER, zaterdag 8 juni 2013 01:24

Beide zijn goede SSDs met de juiste firmware. Beide hebben firmware met datacorruptie-bugs gehad. Maar met de laatste firmware zijn beide stabiel.

Het zijn echter wel SSDs die vallen onder de categorie inherent onbetrouwbaar. Daarmee bedoel ik dat ze noodzakelijke voorzieningen missen die corruptie moeten voorkomen. In het bijzonder gaat het daarbij om power-safe capacitors en RAID5-bitcorrectie. Ook geldt voor beide SSDs dat zij host-writes over de DRAM-chip laten lopen.

Kortom, het zijn eigenlijk heel simpele SSDs met weinig bescherming op papier. Daar staat echter tegenover dat de kwaliteit van de firmware goed valt te noemen. Andere fabrikanten, met name OCZ, laten het op dit punt afweten. Dan kun je alle hardwarematige beveiligingen hebben die je kunt bedenken, maar als de firmware niet stabiel is dan is het eindproduct dat ook niet.

Kortom, de hardware bepaalt de potentie van prestaties en betrouwbaarheid, terwijl de firmware - de software - bepaalt in welke mate deze potentie wordt benut. Voor beide SSDs die je noemt, geldt dat de potentie vrij laag is door gebrek aan geavanceerde voorzieningen, maar dat de firmware wel de hardware juist aanstuurt. Het gevolg is een SSD die goed presteert, goed betaalbaar is en een normale betrouwbaarheid kent. Ze zijn dus niet de beste in hun klasse, maar wel goede middenmoters.

Door Tweakers user analog_, zaterdag 8 juni 2013 08:22

Opinie over early intel SLC modellen? X25-E reeks.

Door Tweakers user H!GHGuY, zaterdag 8 juni 2013 09:57

In het stukje over Annual Failure Rate vertel je dat een SSD veel gelijkmatiger slijt dan een HDD. Dit is niet correct.
SSDs hebben 2 failure curves:
- early fails door slechts NAND chips. Dit kan een fabrikant beperken door in de fabriek de drives enkele keren volledige te beschrijven en wissen.
- late fails door wear & tear

Wanneer je die 2 curves samenlegt, krijg je een bathtub curve

Bij write endurance zeg je dat NAND flash quasi oneindig kan gelezen worden. Ook dit is fout. Iedere keer dat een cel gelezen wordt kan een deeltje van de capaciteit weglekken en kun je fouten krijgen. In vakjargon heet dit "read disturb". Bij MLC en TLC is de kans hierop natuurlijk groter dan bij SLC.

Je haalt aan bij de uitleg van write amplification dat grote bestanden schrijven een lagere write amplification heeft dan kleine bestanden schrijven. Op zich is dit niet helemaal correct. Het probleem is niet het schrijven van de files (want dan krijgt de drive gewoon data binnen en maakt het niet uit of het over kleine of grote files gaat). Het probleem is dat een klein bestand over zijn levensduur een grotere kans heeft om aangepast of herschreven te worden. Pakweg een video van 700MB of een ISO zullen vrijwel niet aangepast worden. Kleine files hebben die neiging wel. Daarom dat bij zakelijk gebruik een grote RAM cache + battery/generator backup de levensduur van de drive significant kunnen verlengen.

Samsung Flash Friendly Filesystem (f2fs) in Linux probeert om daar op in te spelen door een aantal 'streams' naar de drive open te houden. Een stream is eigenlijk gewoon een plaats op de drive waar data naartoe geschreven wordt. Het doel is dan om zo goed en zo kwaad als het kan een onderscheid te maken tussen stabiele data en onstabiele data. Deze worden dan naar de verschillende streams gestuurd. Zo kun je de drive hopelijk helpen om garbage collection te vermijden aangezien data met quasi gelijke levensduur samen op de drive staan.

Oventesten worden wel meer toegepast bij Reliabilty & Durability Testing (RDT) van electronica. Het is effectief zo dat electronica sneller fouten vertoont bij hogere temperatuur. Als je bij kamertemperatuur een foutkans hebt van 0.001% en bij 50°C (een realitischer temperatuur voor testing dan 250°C waarbij weinig chips nog werken ;) ) een kans van 0.1% dan moet je maar 1/100ste van de verwachte levensduur testen.
Iemand als mux kan daar waarschijnlijk een boek (of blog, hint?) over schrijven, maar ik neem het zomaar aan van mijn hardware collega's...

Bij end-to-end databescherming is het voor zover ik weet nog steeds zo dat dit niet echt aanwezig is in huidige implementaties. Hiermee bedoel ik een checksum die door de host gegenereerd wordt bij schrijven en die door de drive mee opgeslagen wordt. Bij het uitlezen van de data wordt deze checksum dan ook tot in de host teruggegeven. Belangrijk is dat ook de SSD controller en eventueel al de SATA/SCSI controller die checksum kunnen controleren. Wat we nu hebben, voor zover ik weet, is dat er over individuele stukken bescherming is (DRAM, PCIe, SATA, NAND) maar dat er alsnog corruptie kan optreden tussen 2 stappen.
ZFS heeft wel een feature waarbij er data checksumming is (en had btrfs dit ook niet?) maar de controller kan dit niet verifieren, dus je weet bij het wegschrijven niet of alles correct is opgeslagen - enkel bij het uitlezen kun je dit weten.
Anderzijds dacht ik dat ze dit bij SCSI wel aan het implementeren zijn (of is het er ondertussen al?)

De spare-area van NAND pages wordt trouwens voor meer dan alleen ECC gebruikt. Data over last write time (om refreshes to doen voor retentie), badblock markeringen, en andere per-block data.

Los van deze schoonheidsfoutjes - mooie blog. Samen met mijn blogje over dit topic hopelijk een goeie gids tov de marketing departementen.

Door Tweakers user Phuncz, zaterdag 8 juni 2013 10:29

Zeer interessant om te lezen en eigenlijk verplicht leesvoer voor elke serieuze tweaker.

Ik merkte wel op dat je nergens de melding maakt dat, hoe inherent veilig een SSD is, icm. een goede firmware, je nog steeds met een product zit dat kan falen. Dat je dus ook nooit een scheduled backup en/of system image mag vergeten te gebruiken.

Misschien niet het punt van je artikel maar het lijkt dat veel mensen, ongeacht hun kennis, dit nog lijken te vergeten.

Door Tweakers user CiPHER, zaterdag 8 juni 2013 10:35

analog_ schreef op zaterdag 08 juni 2013 @ 08:22:
Opinie over early intel SLC modellen? X25-E reeks.
Nog steeds de standaard op het gebied van write endurance. De originele X25-E - codenaam Ephraim - is een SSD met hoge kwaliteit 54nm SLC NAND geheugen bedoelt voor semi-enterprise workloads waar de SSD zwaar wordt belast.

De SSD heeft een zeer goede write endurance van 1 petabyte voor de 32GB versie, waar de nieuwere X25-E modellen hier een capaciteit van 120GB voor nodig hebben om hetzelfde te bereiken. In werkelijkheid hebben de modellen 40GiB en 80GiB aan NAND - net als de X25-M - omdat het een 10-kanaals SSD betreft. Maar omdat de X25-E extra spare space heeft, wordt slechts 32GB van de 40GiB zichtbaar aan de host gepresenteerd. Dit is om de levensduur te bevorderen door een lagere write amplification; iets wat je overigens prima zelf kunt met alle SSDs door simpelweg een gedeelte niet te partitioneren. Dit wordt overprovisioning genoemd en wordt breed toegepast met name voor servers. Gebruikelijk is zelfs om een SSD maar voor de helft te partitioneren en dus te gebruiken, voor een optimale write amplification en dus een maximale levensduur.

De SSD is wel erg duur per gigabyte bruikbare opslag doordat het 'ouderwets' maar zeer betrouwbaar 54nm SLC NAND gebruikt. Verder mist het geavanceerde beschermingstechnieken zoals power-safe capacitors (die zijn opvolger de Intel 710 series wel heeft) en RAID4 bitcorrectie.

Dit is een type SSD die heel lang nuttig blijft voor gebruik in servers. Ouderwets is in geval van NAND helemaal niet zo'n groot nadeel, omdat juist het ouderwetsere NAND een veel hogere write endurance heeft per cell. Daar staat tegenover dat de capaciteit beperkt is en de prijs per gigabyte enorm hoog.

Door Tweakers user CiPHER, zaterdag 8 juni 2013 11:06

H!GHGuY schreef op zaterdag 08 juni 2013 @ 09:57:
In het stukje over Annual Failure Rate vertel je dat een SSD veel gelijkmatiger slijt dan een HDD. Dit is niet correct.
Bathtub curve heb ik gezien, maar eigenlijk geen goede gegevens die dit bevestigen. Tomshardware had een grafiek waarbij meerdere studies naast elkaar worden gelegd, en daar kwam een ander plaatje uit: http://media.bestofmicro....e-rates,4-T-302141-13.png

Kortom, meer gegevens op dit vlak zou wel wenselijk zijn om mij op te baseren. Bathtub is denk ik ook niet heel erg van toepassing voor consumentengebruik omdat failures door het verbruiken van alle write cycles enorm zeldzaam zijn. Voor enterprise gebruikers ligt dat natuurlijk anders.
Bij write endurance zeg je dat NAND flash quasi oneindig kan gelezen worden. Ook dit is fout. Iedere keer dat een cel gelezen wordt kan een deeltje van de capaciteit weglekken en kun je fouten krijgen. In vakjargon heet dit "read disturb".
Voor zover ik begrepen had, gaat dit enkel op voor miljoenen reads zonder dat de cell wordt gewist. Dit is heel anders dan de slijtage door writes, want juist het aantal wisbewerkingen zijn beperkt. In dit opzicht zou het dus wel kloppen dat je vrijwel oneindig kunt lezen, omdat bij normaal gebruik de cells eens in de zoveel tijd worden ververst. Er is dan ook geen sprake van een maximaal aantal readcycles, zoals dat bij writecycles wel het geval is. Tenzij je me kunt aanvullen op dit punt?
Je haalt aan bij de uitleg van write amplification dat grote bestanden schrijven een lagere write amplification heeft dan kleine bestanden schrijven. Op zich is dit niet helemaal correct. Het probleem is niet het schrijven van de files (want dan krijgt de drive gewoon data binnen en maakt het niet uit of het over kleine of grote files gaat). Het probleem is dat een klein bestand over zijn levensduur een grotere kans heeft om aangepast of herschreven te worden.
Dat is toch niet helemaal correct. Waar jij op doelt is het verschil tussen static en dynamic data, waarbij dynamische data die continu wordt aangepast leidt tot een hogere write amplification. Echter, het punt wat adresseerde is dat random writes ook leiden tot een hogere write amplification. Zodra de SSD een steady state bereikt waarbij de vrije erase blocks op zijn, zal een 4K random write namelijk niet zomaar kunnen worden weggeschreven zonder dat een blok van bijvoorbeeld 512K gewist dient te worden. Dit leidt uiteindelijk tot hogere write amplification. Dit effect treed ook op als alle data statisch is en nooit verandert.

Dit effect kun je het meest eenvoudig meten met USB sticks die geen write remapping doen. Dan merk je dat een 4K random write nog langer duurt dan het schrijven van 512K. De Write Amplification gaat hierbij door het dak (hoger dan factor 100) en dat resulteert uiteindelijk in een random write score in de buurt van 0,001MB/s.

Waar jij op doelt is goed te zien in dit plaatje:
http://tweakers.net/ext/f/iUuFcNd0tMhoyCKRYKy8KuyU/full.jpg

Daar zijn de verschillende grafieken verschillende workloads waarbij telkens een ander percentage van de gegevens worden aangepast, wat leidt tot hogere write amplification.
Oventesten worden wel meer toegepast bij Reliabilty & Durability Testing (RDT) van electronica. Het is effectief zo dat electronica sneller fouten vertoont bij hogere temperatuur. Als je bij kamertemperatuur een foutkans hebt van 0.001% en bij 50°C (een realitischer temperatuur voor testing dan 250°C waarbij weinig chips nog werken ;) )
Voor zover ik heb begrepen wordt op zowel 150 graden als 250 graden getest. Ik heb mij daarop op de volgende gegevens gebaseerd:

1008 hours at 150°C = 1150 years at 25°C
1008 hours at 150°C = 60 years at 55°C
24 hours at 250°C = 1800 years at 25°C
24 hours at 250°C = 100 years at 55°C

Testen op 55 graden lijkt mij dus ondoenlijk omdat er ongeveer een factor 18 verschil zit tussen 25 graden en 55 graden, en dat is te weinig lijkt mij?
Bij end-to-end databescherming is het voor zover ik weet nog steeds zo dat dit niet echt aanwezig is in huidige implementaties. Hiermee bedoel ik een checksum die door de host gegenereerd wordt bij schrijven en die door de drive mee opgeslagen wordt.
Ja waar jij op doelt is de enterprise-uitvoering van End-to-End data integrity, die verder gaat dan het opslagapparaat zelf en in feite de gehele chain beveiligd door checksums van host via controller naar opslagapparaat en weer terug te laten bewaken. Maar in de uitvoering van consumenten SSDs gaat dit niet verder dan de integriteit te bewaken binnen het opslagapparaat zelf. Dat is al een grote stap: dat zodra de data in handen is van het opslagapparaat deze garandeert dat deze niet corrupt raakt. Met name corruptie door de DRAM-chip is hierbij een belangrijke bescherming. Overigens hebben ook consumenten hardeschijven deze feature. Waar jij op doelt is de enterprise variant die deze bescherming uitbreidt tot buiten het opslagapparaat zelf.
ZFS heeft wel een feature waarbij er data checksumming is (en had btrfs dit ook niet?) maar de controller kan dit niet verifieren, dus je weet bij het wegschrijven niet of alles correct is opgeslagen - enkel bij het uitlezen kun je dit weten.
Alle derde generatie filesystems (ZFS, Btrfs en ReFS) doen aan checksums. Voor legacy software moet je dan peperdure enterprise hardware gebruiken. In feite zijn dit twee verschillende wegen: of je gebruikt domme software met peperdure hardware (enterprise) of je gebruikt slimme software met goedkope hardware (ZFS). Interessant hierbij is dat RAID ontstaan is uit dezelfde afweging en intelligentie op software-niveau wilde gebruiken om van goedkope hardware toch een betrouwbaar opslagvolume te destilleren. Waarbij RAID dit amper is gelukt, is dit bij ZFS wel goed gelukt. Ironisch is dan ook dat ZFS in feite geen RAID is, doordat het geen louter LBA-achtige specificatie van on-disk layout is, maar een verwevenheid tussen filesystem en LBA-storage.
De spare-area van NAND pages wordt trouwens voor meer dan alleen ECC gebruikt. Data over last write time (om refreshes to doen voor retentie), badblock markeringen, en andere per-block data.
Dat had ik ook ooit gelezen, met name dat punt over de timestamp opslaan in de spare area t.b.v. bewaken van de retentie. Echter, ik kan dit nu niet meer terugvinden. En ik schrijf liever geen dingen die ik niet zeker weet en me ook niet meer kan baseren op een goede paper op dit punt. Mocht jij die wel hebben, hoor ik dat graag. Dan kan ik dat nog toevoegen aan het artikel.

Wat betreft factory bad blocks; ik dacht dat dit juist niet in de spare area maar juist in de spare space (heerlijk verwarrend die twee!) werd opgeslagen, waar ook de mapping tables zijn gehuisvest. Zoals altijd: bronnen zijn welkom!

Hartelijk dank voor je feedback weer! :)

Door SSD_User, zaterdag 8 juni 2013 13:32

Hoi CiPHER,

Bedankt voor dit interessante verhaal. Ik word met mijn Intel 520 geconfronteerd met de vervelende eigenschap van windows (W7 SP1) dat iedere correcte shutdown gezien wordt als unexpected power loss. En dit wordt netjes geteld in ChrystalDiskInfo.

Je schrijft echter in je blog: "Onder andere Windows heeft dergelijke bugs gekend" . Het woord "gekend" impliceert dat het probleem opgelost zou zijn. In mijn PC blijkt dit dus echter niet het geval te zijn. Is hier een oplossing voor?

Door Tweakers user H!GHGuY, zaterdag 8 juni 2013 13:39

CiPHER schreef op zaterdag 08 juni 2013 @ 11:06:
Bathtub curve heb ik gezien, maar eigenlijk geen goede gegevens die dit bevestigen. Tomshardware had een grafiek waarbij meerdere studies naast elkaar worden gelegd, en daar kwam een ander plaatje uit: http://media.bestofmicro....e-rates,4-T-302141-13.png

Kortom, meer gegevens op dit vlak zou wel wenselijk zijn om mij op te baseren. Bathtub is denk ik ook niet heel erg van toepassing voor consumentengebruik omdat failures door het verbruiken van alle write cycles enorm zeldzaam zijn. Voor enterprise gebruikers ligt dat natuurlijk anders.
Die bathtub curve heb ik uit informatie van een vendor. De fabrikant kan echter door factory testen (de SSD een 5-10tal keer schrijven+wissen) het gros van de early fails eruit halen. Wat je dan tegenkomt bij verkochte units lijkt op de curve die jij toont. Wanneer een fabrikant die testing niet doet heb je echter een onevenredig hoge uitval bij recente drives.
Voor zover ik begrepen had, gaat dit enkel op voor miljoenen reads zonder dat de cell wordt gewist. Dit is heel anders dan de slijtage door writes, want juist het aantal wisbewerkingen zijn beperkt. In dit opzicht zou het dus wel kloppen dat je vrijwel oneindig kunt lezen, omdat bij normaal gebruik de cells eens in de zoveel tijd worden ververst. Er is dan ook geen sprake van een maximaal aantal readcycles, zoals dat bij writecycles wel het geval is. Tenzij je me kunt aanvullen op dit punt?
Weerom, dit is uit ervaringen met SSDs en informatie van vendors. Exacte getallen over de kans van zo'n read disturb heb ik niet, maar er is wel degelijk kans (hoewel zeer klein) op data verlies bij frequent lezen van dezelfde data.
Bij het gros van de SSDs echter wordt door de wear-leveling de boel snel genoeg geroteerd zodat de kans om dit voor te hebben minimaal is.
Dat is toch niet helemaal correct. Waar jij op doelt is het verschil tussen static en dynamic data, waarbij dynamische data die continu wordt aangepast leidt tot een hogere write amplification. Echter, het punt wat adresseerde is dat random writes ook leiden tot een hogere write amplification. Zodra de SSD een steady state bereikt waarbij de vrije erase blocks op zijn, zal een 4K random write namelijk niet zomaar kunnen worden weggeschreven zonder dat een blok van bijvoorbeeld 512K gewist dient te worden. Dit leidt uiteindelijk tot hogere write amplification. Dit effect treed ook op als alle data statisch is en nooit verandert.

Dit effect kun je het meest eenvoudig meten met USB sticks die geen write remapping doen. Dan merk je dat een 4K random write nog langer duurt dan het schrijven van 512K. De Write Amplification gaat hierbij door het dak (hoger dan factor 100) en dat resulteert uiteindelijk in een random write score in de buurt van 0,001MB/s.

Waar jij op doelt is goed te zien in dit plaatje:
http://tweakers.net/ext/f/iUuFcNd0tMhoyCKRYKy8KuyU/full.jpg

Daar zijn de verschillende grafieken verschillende workloads waarbij telkens een ander percentage van de gegevens worden aangepast, wat leidt tot hogere write amplification.
Ik dacht dat we het hadden over hedendaagse drives met TRIM support ;)
Maar zelfs bij oude drives zonder TRIM die volledig gevuld zijn geraakt maakt het voor de drive weinig uit of het een datastream is van een groot bestand of vele kleintjes. Het punt zit hem daar beperkt in de fragmentatie van je filesystem (de SSD kan namelijk enigszins aannemen dat een OS zijn best doet om data van dezelfde files in aaneensluitende blocken weg te schrijven - wat de meeste FS'en ook proberen) en in grootste mate in die van de logical->physical mapping. Hoe meer fragmentatie hoe meer garbage collection je nodig hebt (en misschien zelfs live GC bij elke write).
Je kan vanuit het perspectief van de SSD hetzelfde access pattern verkrijgen bij het wegschrijven van een 700MB ISO op een filesystem met grote fragmentatie als bij het wegschrijven van 700MB aan 8KB files.
[...]
Voor zover ik heb begrepen wordt op zowel 150 graden als 250 graden getest. Ik heb mij daarop op de volgende gegevens gebaseerd:

1008 hours at 150°C = 1150 years at 25°C
1008 hours at 150°C = 60 years at 55°C
24 hours at 250°C = 1800 years at 25°C
24 hours at 250°C = 100 years at 55°C

Testen op 55 graden lijkt mij dus ondoenlijk omdat er ongeveer een factor 18 verschil zit tussen 25 graden en 55 graden, en dat is te weinig lijkt mij?
Het probleem is dat veel chips maar gespec'd zijn tot temperaturen van 70-110°C. Een datasheet die ik heb vermeld een max ambient van 70°C, dus reken op iets van een 80°C junctie-temperatuur. Je kan zo'n chip dus gewoon niet op 250°C testen.
Dit kan je ten dele oplossen door een grotere sample size te nemen. Ipv 1 toestel test je er 20 op 55°C bijvoorbeeld en dat enkele maanden lang.
Dat had ik ook ooit gelezen, met name dat punt over de timestamp opslaan in de spare area t.b.v. bewaken van de retentie. Echter, ik kan dit nu niet meer terugvinden. En ik schrijf liever geen dingen die ik niet zeker weet en me ook niet meer kan baseren op een goede paper op dit punt. Mocht jij die wel hebben, hoor ik dat graag. Dan kan ik dat nog toevoegen aan het artikel.
Hier heb ik geen referenties voor, maar vanuit common-sense lijkt het me wel logisch ;)
Een timestamp embedden als je dan toch aan het schrijven bent zou niet meer dan normaal moeten zijn.
Je zou die timestamp zelfs per erase-block kunnen opslaan op het moment dat je de eerste blok wegschrijft. In de meeste gevallen is het waarschijnlijk echter zo dat zo'n timestamp eerder zal dienen als een soort van least-recently-written informatie om de volgende kandidaat voor garbage-collection/wear-leveling te zoeken.
Wat betreft factory bad blocks; ik dacht dat dit juist niet in de spare area maar juist in de spare space (heerlijk verwarrend die twee!) werd opgeslagen, waar ook de mapping tables zijn gehuisvest. Zoals altijd: bronnen zijn welkom!
Wat SSDs betreft weet ik het niet - dit is allemaal "secret sauce" van de vendors. Maar als je kijkt naar hoe flash filesystems in Linux worden gemanaged, dan zie je dat:
- er een bad block table is die een lijst bevat van bad blocks
- de bad blocks worden gemarkeerd door een byte in de spare area voor het geval de BBT corrupt raakt en scanning nodig is.
Eigenlijk heb je niet meer dan een bit - of een magic sequence nodig om een bad block te markeren - je gebruikt hem namelijk anders toch niet meer.
Hartelijk dank voor je feedback weer! :)
Graag gedaan, het houdt ons scherp ;) - diepgaande artikels/blogs zoals deze mogen wat mij betreft wel meer gepost worden.

Ars Technica had overigens een tijd terug een uitstekend artikel over SSDs:
http://arstechnica.com/in...-state-disks-really-work/
Ik kan het iedereen met interesse in SSDs aanbevelen.

Merk trouwens op dat de markt voor non-volatile storage weer aan de vooravond staat van veranderingen. SSDs gaan niet eeuwig sneller en kleiner worden door de fysische beperkingen. Enkelen beweren zelfs dat vooraleer de SSD markt uitsterft het vendor-landschap nog behoorlijk zal veranderen. Door de toenemende verkleining zouden controllers meer en meer afgestemd zijn op de flash die erbij hoort. Dit zou ervoor zorgen dat enkel nog manufacturers die zowel controller als flash maken nog rendabel SSDs kunnen maken. De vele 'rebrands' (zie SandForce afgeleiden) zouden daarmee een stille dood tegemoetgaan.
Maar er zal nog wel wat water naar de zee vloeien eer we zover zijn...

Door Tweakers user mux, zondag 9 juni 2013 15:04

Ik heb wel zin om wat te reageren, maar pfffffffffffff wat een epistels worden hier geschreven! Allereerst wat vragen aan CiPHER:
- Waar heb je die failure rates vandaan? Geen enkel bedrijf kan leven met meer dan ~5% failure rate, laat staan 50% (!!!!!!!!!) (!!!!!!!!!!!!!!!!!!!!) (meer uitroeptekens!). OCZ moet echt idioot veel geld in de bank hebben gehad om dat te overleven, of elders hele goede producten hebben verkocht met flinke marge.
- Was het puur de schuld van de Indilinx Everest-controller dat de Octane en Petrol het zo slecht deden, of was het ook OCZ's extreem dodgy NAND-inkoopbeleid?
- In het algemeen: wat zijn jouw gedachten over de failure modes van OCZ schijven? Ik heb zo m'n theorieën, maar ik heb er eerlijk gezegd nog geen whitepapers of andere nuttige documenten over gelezen.
- Jammer dat je end-to-end data security niet verder hebt uitgewerkt, daar zie ik graag nog eens wat meer over! Er is hier extreem veel over te zeggen, en het is een ontzettend multidisciplinair veld.
- Heb je literatuur over de failure-over-time curves voor SSDs? Wat Highguy zegt over de bathtub curve is trouwens ook achterhaald - bathtub curves zijn extreem overused, en slechts in erg zeldzame gevallen werkelijkheid.

Een paar losse comments:
Supercaps e.d.. Het is prachtig als je ultracaps of simpelweg grote elektrolytische condensatoren gebruikt voor energie-opslag, maar het blijft een mitigation voor een schijf die te sloom is. Belangrijker nog: met name ultracondensatoren zijn een hele slechte energie-opslag, want ze hebben een belabberde levensduur. Typisch kun je rekenen op 1000-2000h @ 55C (met de gebruikelijke factor 2 extra voor elke 10 graden lagere temperatuur). Je bent dus zo goed als gegarandeerd van failure van dit systeem gedurende de levensduur van je schijf. Nou zullen ze vast wel hun huiswerk hebben gedaan en ervoor hebben gezorgd dat deze caps in gedegradeerde staat nog steeds genoeg energie kunnen vasthouden om de schijf een emergency dump te laten doen, maar het blijft brak. En het wordt niet beter:
- Flash-geheugen zal alleen maar meer energie per bit nodig gaan hebben in de toekomst, en cached user/maintenance data zal alleen maar toenemen
- Controllers zullen complexer worden en dus niet significant minder energie nodig hebben voor het uitvoeren van zo'n emergency dump
- SSDs worden alleen maar kleiner, dus minder ruimte voor energy storage.

En dat is eigenlijk het fundamentele probleem met die energie-opslag: er is te weinig ruimte om andere (beter geschikte) energie-opslagoplossingen in een SSD te proppen, en dus moeten ze grijpen naar een brakke, doch de enige mogelijke route. In de toekomst gaat men hier tegenaan lopen. Hoe wordt dat opgelost? Alleen nog backup batteries op PCIe-achtige form factors? Lithium-chemie batterijen ipv caps? Lastig te zeggen.

High temperature testing. Dit gaat uit van een heel erg simpele regel: de wet van Arrhenius. Die zegt dat een chemische reactie ongeveer 2 keer zo hard gaat als je de temperatuur 10K hoger maakt (althans, Arrhenius zegt dat de verhouding tussen de twee logaritmisch is, en de cijfers die ik hier invul zijn vuistregels binnen chemie). Dit is bijvoorbeeld een ontzettend goede voorspeller van de levensduur van puur fysisch-chemische elektronische componenten zoals condensatoren en analoge silicium-onderdelen (zoals NAND). Echter, het is geen orthogonale maat voor levensduur, want de levensduur van zo goed als alles heeft zowel temperatuurafhankelijke als niet-temperatuurafhankelijke eigenschappen. Daarnaast kun je een hoop componenten in de praktijk niet testen omdat ze smelten, demagnetiseren of anderszins tegen limieten van de materialen aanlopen.

Dus, high temperature testing is waardeloos, toch? Nope! Natuurlijk weet iedereen die high temperature testing doet dit, en er wordt niet alleen op 250 graden getest en vervolgens geëxtrapoleerd - er wordt veel uitgebreider getest om te verifiëren dat een testmethode voldoende indicatie geeft van de werkelijkheid. Er wordt bovendien met gigantische marges (meestal een orde-grootte) gewerkt. Niet zonder reden: ze zes-sigma waarde is van belang voor componentenfabrikanten: je wil op zijn minst 6 standaarddeviaties binnen het gestelde betrouwbaarheidsgebied zitten. En de mensen die hier verantwoordelijk voor zijn zullen absoluut hun huiswerk hierop hebben gedaan :)

Hm, ik had hier meer willen vertellen maar ben stiekum al meer dan drie kwartier bezig met dit + het lezen van het blog. Terug aan het werk!

Door Tweakers user CiPHER, zondag 9 juni 2013 16:06

mux schreef op zondag 09 juni 2013 @ 15:04:
Ik heb wel zin om wat te reageren, maar pfffffffffffff wat een epistels worden hier geschreven!
}>
Allereerst wat vragen aan CiPHER:
- Waar heb je die failure rates vandaan? Geen enkel bedrijf kan leven met meer dan ~5% failure rate, laat staan 50% (!!!!!!!!!) (!!!!!!!!!!!!!!!!!!!!) (meer uitroeptekens!). OCZ moet echt idioot veel geld in de bank hebben gehad om dat te overleven, of elders hele goede producten hebben verkocht met flinke marge.
De failure rates heb ik van de Franse Retailer die als één van de weinige onafhankelijke bronnen geldt voor bruikbare SSD failure statistieken. In werkelijkheid zijn de failure statistieken van OCZ en Samsung hoger omdat zij anders dan de andere fabrikanten RMA direct met de klant afhandelen. De gemeten rates door de distributeur zijn dus slechts een gedeelte van de totale RMA rates. URL stond in het artikel overigens. :)

Verder moet je weten dat 9 van de 10 defecte OCZ SSDs een locked SSD betreft ofwel een corrupte SSD die weer tot leven kan worden gewekt door het resetten van de mapping tables (secure erase). Dat is dan ook wat OCZ doet, en dezelfde SSD gaat na het wissen van de SMART weer retour naar een andere klant. En die klanten maar blij zijn met de 'goede service'. :o

Verder vangt OCZ vaak extra geld door als eerste op nieuwe ontwikkelingen te storten, zoals toen bij 25nm NAND waarbij klanten een minderwaardige SSD kregen met bovendien minder opslagruimte dan op het doosje stond (55GB ipv 60GB; 115GB ipv 120GB). OCZ heeft toen flink centjes gecached door als eerste fabrikant goedkoper in te kopen en voor dezelfde prijs te verkopen. Dus dat zijn cache-momenten voor OCZ. Desondanks maakt het bedrijf al een tijd geen winst en staat het er financiëel slecht voor. Ze hebben ook al tijden hun 3e kwartaalcijfers niet ingeleverd en daar krijgen ze nu een proces mee aan de broek. Prima zo, laten we hopen dat dat bedrijf eens een goede rotschop krijgt, hopelijk een fatale.

In het verleden is OCZ ook het bedrijf geweest wat OEM DRAM-geheugenchips opkocht, de SPD hiervan herprogrammeerde en dus overclockte, en vervolgens als duur overclockgeheugen doorverkocht, met een mooie heatsink op de modules zodat de DRAM-chips onzichtbaar werden. Dan weet je ongeveer wat voor bedrijf OCZ is.
- Was het puur de schuld van de Indilinx Everest-controller dat de Octane en Petrol het zo slecht deden, of was het ook OCZ's extreem dodgy NAND-inkoopbeleid?
Indilinx bestaat niet meer. De grap is dat OCZ Indilinx heeft gekocht en hun nieuwe controller ook naar Indilinx heeft vernoemd. Maar zowel de firmware als de hardware heeft niets met Indilinx te maken. Waarschijnlijk gaat het over intellectueel eigendom cq. patenten, maar verder lijkt het mij onzin dat OCZ nu een controllerfabrikant heeft gekocht waarmee het betere controllers kan ontwerpen. Ze zijn gewoon zelf aan de slag gegaan met hun eigen brouwseltje. En we zien daarvan het resultaat. Afraffelen betekent lage kwaliteit firmware met asociaal en haast crimineel hoge failure rates tot gevolg. Daar zakt OCZ keihard door de mand.

Overigens halveren de failure rates van OCZ van ~6.6% naar ~3% als je de Petrol en Octane niet meerekent. Maar zelfs zonder deze crap SSDs is de failure rate van OCZ nog steeds ongeveer een factor 18 hoger dan Intel. En dan hebben we dus nog niet eerlijk gerekend omdat OCZ ook failures direct met de klant afhandelt.

Maar ze overleven dus doordat ze gefaalde SSDs ook continu weer retour sturen naar hun klanten. Anders zouden ze allang het loodje hebben gelegd. En als de klant voor de 3e maal een SSD terug krijgt die na een paar weken sterft, dan kopen ze gewoon een echte SSD en zijn ze van het gezeik af.
In het algemeen: wat zijn jouw gedachten over de failure modes van OCZ schijven? Ik heb zo m'n theorieën, maar ik heb er eerlijk gezegd nog geen whitepapers of andere nuttige documenten over gelezen.
Een medewerker van OCZ heeft een tijd geleden op het forum laten ontvallen dat 9 van de 10 geretourneerde SSDs niet echt fysiek defect zijn maar 'panic locked'. Dat houdt in dat er corruptie is aan de mapping tables. Dit kan komen door corruptie door onvoldoende beschermingsfuncties zoals ECC en bitcorrectie, maar logischer is fouten in de firmware. OCZ heeft dan ook heel veel firmwareupdates en hun klanten zijn uitstekende testpiloten die als bètatesters fungeren om te kijken of de nieuwe firmware nu eindelijk wel de failure rates omlaag kan brengen.
Jammer dat je end-to-end data security niet verder hebt uitgewerkt, daar zie ik graag nog eens wat meer over! Er is hier extreem veel over te zeggen, en het is een ontzettend multidisciplinair veld.
Tja, het is meer een enterprise-feature. Voor consumentenproducten is End-to-End data security niets meer dan een CRC-beveiliging voor met name de DRAM-chip, zodat corruptie door de DRAM-chip kan worden gedetecteert. Voor enterprisegebruikers wordt dit uitgebreid benut om de hele keten inclusief controller te beschermen tegen corruptie.

Maar ik vind het eigenlijk niet zo interessant, gek genoeg. Het is de software - het filesystem - wat veel beter kan beschermen. Zoals ik al schreef tegen H!GHGuY: je hebt twee wegen:

1) domme software met peperdure hardware gebruiken; dus weinig intelligentie en bescherming in de software maar de hardware zo perfect mogelijk maken omdat de software simpelweg veronderstelt dat de hardware perfect is.

2) slimme software met goedkope hardware gebruiken; dus de software aanpassen aan de gebreken van hardeschijven. In het bijzonder gaat het daarbij om bad sectors. De software gaat dus niet langer uit van een 'perfect' opslagapparaat, maar kan ook omgaan met hardeschijven die prima werken maar wel af en toe bad sectors genereren.

Ik vind de tweede weg veel logischer en beter. Maar daar verdienen de grote heren niet zoveel aan. Dus innovatie wordt vaak ook bewust tegengewerkt om marktsegregatie te bevorderen; men wil centjes zien van de grootzakelijke klanten die die centjes kunnen betalen. Om dezelfde reden hebben consumenten geen beschikking over ECC geheugen. Dit terwijl de kosten hooguit met 1/8e of 1/16e zouden stijgen. Dat is het natuurlijk wel waard. Maar dat zou kunnen betekenen dat zakelijke klanten ook het goedkope consumentenspul gaan gebruiken, en dat wil 'de industrie' niet.
Heb je literatuur over de failure-over-time curves voor SSDs?
Alleen het artikel van Tomshardware, waar meerdere studies naast elkaar worden gelegd. Niet echt een heel wetenschappelijke analyse. Maar het idee dat failures van SSDs veel meer lineair zijn dan bij hardeschijven klopt denk ik wel.
Supercaps e.d..
Supercapacitors worden tegenwoordig nauwelijks gebruikt. De zakelijke klanten wilden eerder een batterij van kleinere capacitors omdat hier redundantie kan worden aangebracht en dus netto betrouwbaarder is dan een single point of failure. Daarnaast is het zo dat softwaretechnieken de noodzaak voor noodstroom kunnen verzachten door de window of opportunity kleiner te maken waarbinnen corruptie kan plaatsvinden en anderzijds de tijd die benodigd is voor het leveren van noodstroom wordt verkort. Zo zijn de mapping tables tegenwoordig transaction-based, waar met journaling dus een rollback kan plaatsvinden zodra het apparaat weer stroom heeft. Dit kan wel zorgen voor tragere boots overigens, maar beter dat dan een corrupte SSD.

En bedenk ook dat noodstroom vooral nodig is met de huidige generatie SSDs op basis van NAND. Dit omdat NAND de nare eigenschap heeft dat grote blokken eerst gewist moeten worden voordat bestaande data kan worden overschreven. Andere solid state geheugentechnieken zoals PCM en MRAM hebben deze eigenschap niet, en zijn dus geschikte opvolgers van NAND. Dit betekent uiteindelijk dat controllerchips minder ingewikkeld en daardoor betrouwbaarder kunnen worden, omdat er geen mapping tables meer nodig zullen zijn en er dus een grote point of failure minder is. De complexiteit van de huidige SSDs is minimaal aan 90% van alle failures debet. Dat lijkt mij een heel veilige aanname, en dus ook onderkend door OCZ zelf.
Dus, high temperature testing is waardeloos, toch? Nope! Natuurlijk weet iedereen die high temperature testing doet dit, en er wordt niet alleen op 250 graden getest en vervolgens geëxtrapoleerd - er wordt veel uitgebreider getest om te verifiëren dat een testmethode voldoende indicatie geeft van de werkelijkheid.
Het blijft toch een bakker die zijn eigen brood test. Ze willen het stickertje opplakken waarmee ze (zogenaamd) voldoen aan de certificatie van de JEDEC, dan kunnen ze hun spulletjes verkopen. Dus wat je zegt dat ze er toch echt wel voor zorgen dat hun product echt goed is; tsja... Ik heb er mijn twijfels bij. Waarschijnlijk bestaan er echt wel verschillen op gebied van Quality Assurance tussen kwaliteitsbakkers zoals Micron en foundries die in de marge opereren.

Ook jij hartelijk dank voor je feedback natuurlijk! We komen ongetwijfeld terug op sommige punten in volgende blogs. :)

Door Tweakers user F.West98, zondag 9 juni 2013 23:04

Nog een vraagje, ik had net een BSoD (voor het eerst in 2+ jaar). Hij ging eerst nog debuggen en die gegevens ook wegschrijven.

Telt dat ook als Unexpected Power-Loss?

Door Tweakers user GTX2GvO, maandag 10 juni 2013 09:32

Je zou haast zeggen dat een SSD ipv capacitors een kleine accu dient te hebben om tijdens het "afsluiten" zijn taken te voltooien.

Zo zou bv het systeem al volledig uit kunnen staan terwijl de SSD nog even zijn laatste writes wegwerkt en netjes kan stoppen.

Door Tweakers user H!GHGuY, maandag 10 juni 2013 12:37

F.West98 schreef op zondag 09 juni 2013 @ 23:04:
Nog een vraagje, ik had net een BSoD (voor het eerst in 2+ jaar). Hij ging eerst nog debuggen en die gegevens ook wegschrijven.

Telt dat ook als Unexpected Power-Loss?
Hangt van de implementatie van windows af. Gezien Windows nog data weg kon schrijven zou ik verwachten dat het niet meetelt, maar zeker kan ik dit niet zeggen.
mux schreef op zondag 09 juni 2013 @ 15:04:
- Heb je literatuur over de failure-over-time curves voor SSDs? Wat Highguy zegt over de bathtub curve is trouwens ook achterhaald - bathtub curves zijn extreem overused, en slechts in erg zeldzame gevallen werkelijkheid.
Deze links lijken dit voor NAND toch te bevestigen:
http://www.ti.com/lit/an/slaa392/slaa392.pdf
http://www.digikey.be/Web%20Export/Supplier%20Content/enpirion-1280/pdf/enpirion-white-paper-enterprise-ssd-reliability.pdf?redirected=1
http://blogs.law.harvard.edu/philg/2011/10/27/why-arent-ssd-or-hybrid-disk-drives-more-popular-in-laptop-computers/
CiPHER schreef op zondag 09 juni 2013 @ 16:06:
Maar ik vind het eigenlijk niet zo interessant, gek genoeg. Het is de software - het filesystem - wat veel beter kan beschermen. Zoals ik al schreef tegen H!GHGuY: je hebt twee wegen:

1) domme software met peperdure hardware gebruiken; dus weinig intelligentie en bescherming in de software maar de hardware zo perfect mogelijk maken omdat de software simpelweg veronderstelt dat de hardware perfect is.

2) slimme software met goedkope hardware gebruiken; dus de software aanpassen aan de gebreken van hardeschijven. In het bijzonder gaat het daarbij om bad sectors. De software gaat dus niet langer uit van een 'perfect' opslagapparaat, maar kan ook omgaan met hardeschijven die prima werken maar wel af en toe bad sectors genereren.

Ik vind de tweede weg veel logischer en beter. Maar daar verdienen de grote heren niet zoveel aan. Dus innovatie wordt vaak ook bewust tegengewerkt om marktsegregatie te bevorderen; men wil centjes zien van de grootzakelijke klanten die die centjes kunnen betalen.
Er is eigenlijk nog een bijkomende reden: bij ZFS weet je pas dat er corruptie was als je de data later opnieuw uitleest en ziet dat ze fout is als de checksum niet matcht. Mogelijks ben je dan ook data verloren aangezien het CRC is en geen ECC.
Bij echte end-to-end beveiliging kan het subsysteem die de fout heeft veroorzaakt of ontvangen je meteen vertellen als er een probleem is opgetreden _en_ is de plaats waar de fout is opgetreden ook meteen gekend.
Je S/W kan dan onmiddellijk correct actie nemen (badblock markeren en doorgaan, data opnieuw verzenden, drive hotswappen voor een spare-drive, ...)

Door Tweakers user CiPHER, maandag 10 juni 2013 12:51

Er is eigenlijk nog een bijkomende reden: bij ZFS weet je pas dat er corruptie was als je de data later opnieuw uitleest en ziet dat ze fout is als de checksum niet matcht. Mogelijks ben je dan ook data verloren aangezien het CRC is en geen ECC.
ZFS probeert niet te beveiligen door foutcorrectie toe te passen; daar heb je weinig aan als een hardeschijf een hele sector (van 4K) niet wilt sturen omdat deze niet door de ECC heen komt. Dus foutcorrectie aan de kant van ZFS is in dit geval onzinnig.

Veel logischer is om de data dan van een andere disk te lezen. Dat gebeurt dan ook bij redundante configuraties. Bij een single disk configuratie zijn er altijd nog ditto blocks wat kopieën zijn van de data. Deze worden het liefst op andere schijven geplaatst maar bij een single disk configuratie kan dat natuurlijk niet. Maar dan ben je nog steeds beschermd tegen bad sectors. Standaard wordt echter alleen filesystem metadata van dergelijke kopieën voorzien. Normale bestanden zullen dus corrupt en ontoegankelijk worden. ZFS beschermt de applicaties zodat zij nooit corrupte gegevens te zien krijgen, als de corruptie niet ter plekke kan worden gecorrigeerd dan wordt het bestand ontoegankelijk en zie je dat in de pool status, waar een lijst met ontoegankelijke bestanden te zien zal zijn. Voor veel mensen is dit al een heel belangrijke feature, filesystem metadata redundantie en simpelweg het detecteren van corruptie. Als je het maar weet! Niet weten is silent corruption en dat kan zo irritant zijn. Dan kom je een half jaar later erachter dat al je trouwfoto's corrupt zijn en dat die corruptie keihard is doorgestroomd naar je backups. Je hebt toch echt gevalideerde metadata nodig voor een betrouwbaar opslagsysteem.

In een redundante configuratie is ZFS vrijwel immuun voor bad sectors. Honderden tot duizenden bad sectors verdeeld over alle disks kan dan geen enkel probleem zijn. En beter nog: ze worden automatisch gefixed zodra ontdekt. Je hebt wel gelijk dat corruptie pas wordt opgemerkt als de data aangesproken wordt, maar daarvoor kun je een twee-wekelijkse scrub activeren.

ZFS is simpelweg geweldig voor bad sectors en corruptie. Voor SSDs ligt het net wat anders omdat een corrupte SSD totaal ontoegankelijk kan worden zoals bij corruptie in de mapping tables. Maar ZFS gebruikt SSDs veelal als cache en anders dan bij veel cachingsystemen kan ZFS wél corruptie detecteren op de cache SSD. In dat geval leest het gewoon van hardeschijf-array.

Kortom, ZFS is echt een next-generation filesystem die betrouwbaarheid naar een veel hoger niveau tilt. Het verschil in bescherming met een tweede-generatie filesystem is gigantisch.

Door Tweakers user IceStorm, vrijdag 14 juni 2013 15:15

Ik hou het even bij: _/-\o_ (zowel voor de blog als de reacties ;)).

Door Tweakers user Buggle, donderdag 20 juni 2013 14:49

Super bedankt voor deze informatie, maar ik word er wel een beetje bang door gemaakt om eerlijk te zijn. Ik denk dat je voordat je in de materie duikt misschien een stukje moet schrijven over backups, en hoe die gedurende de tijd dat de computer wel gewoon normaal draait betrouwbaar gemaakt (moeten kunnen) worden. Dan is het ook minder boeiend als er met het wegschrijven eens een bitje de nek omgedraaid wordt. Per slot van rekening is het met de betrouwbaarheid van dit soort dingen net zoals de bescherming van ons land tegen water: je wilt meerdere dijken achter elkaar hebben, waarbij alleen je onbelangrijke dingen bij wijze van spreken in de uiterwaard mogen staan. Je windows installatie kun je zo opnieuw installeren, en het maakt dus niet zo heel erg veel uit (wil zeggen: is niet onoverkoombaar) in vergelijking tot het afronden van je master thesis een paar dagen voor de deadline. Die sla je dan ook op gedurende normaal gebruik van je computer, misschien zelfs direct in je dropbox. En daarna maak je er meteen een PDF van, bijvoorbeeld. Voor midden-gevoelige data kun je aan je belastingaangifte denken. Zou behoorlijk klote zijn als die corrupt raakt, maar ook die kun je opnieuw maken en uitstel aanvragen. Maargoed, hierbij denk ik dan vooral vanuit het oogpunt van de consument. Een en ander betekent dus dat ik het persoonlijk vanuit mijn logica niet echt een issue vind onder die omstandigheden, mits er gebruik gemaakt wordt van de juiste tools (plaatselijke backup, cloudoplossing en evt. nog een offsite backup). In de afgelopen twee jaar ben ik dagelijks met een groot document bezig geweest (master thesis, ahum, kuch, schaam - wel eindelijk klaar nu), en die heb ik steeds direct in mijn dropbox opgeslagen, een paar keer per week in een nieuw bestand en regelmatig ook een PDF gemaakt mocht de docx overlijden.
Onder die omstandigheden denk ik echt dat het niet zoveel uitmaakt wat voor hardwarematige betrouwbaarheidsaspecten je SSD heeft, als hij maar stabiele firmware heeft (e.g. Intel, Samsung, Crucial, Plextor) en kan detecteren wanneer iets fout is gegaan. Goed, jij weet er natuurlijk veel en veel meer van dan ik (ik ben maar een simpele civiel ingenieur), maar dit is wat mijn logica mij zegt.

Ik ben dan vooral erg benieuwd in deze context hoe windows tegenwoordig met corruptie omgaat. Windows 8 bijvoorbeeld heeft veel betere herstelmechanismen; misschien heeft dat hier ook mee te maken. Mijn ervaringen van de laatste tijd zijn daarin gemixt; mijn computer (win7) geeft bij het booten de laatste tijd steevast een CMOS CRC error, en die blijft steeds weer terugkomen. Dat duidt erop dat windows iets geks doet bij het opstarten of afsluiten. Ik had ook een tijdje af en toe een BSOD bij het opstarten of afsluiten, maar dat bleek door mijn Ramdisk te komen. Dat probleem heb ik opgelost, maar de CMOS corruptie blijft terugkomen (ondanks BIOS updates en jumper-resets). Moederbord is overigens een Intel DH67CF.
Soms wilde mijn windows installatie (daardoor) niet meer opstarten, en ook de reparatie kon dan geen problemen vinden, maar na een of twee keer proberen, gewoon wat rondkloten omdat ik geen idee heb wat ik doe (lol), werkte het dan wel ineens weer. De SSD in die computer is trouwens een Crucial M4 gekocht als een Adrenaline. Dat was zo ongeveer de miskoop van de eeuw, maar dat is weer een heel ander verhaal (over betrouwbaarheid van HDD's gesproken, met mijn Samsung's heb ik hele vreemde dingen meegemaakt in die context).

Edit: nu ik toch bezig ben, ik heb net (d.w.z. twee uurtjes geleden :)) een Plextor M5S gekocht voor mijn moeder. Volgens mij is dat best een betrouwbaar ding, niet? Gebruikt dezelfde controller als in de M4, bewezen en volwassen dus. De voortekenen zijn goed. Enige dat ik raar vind is dat het ding nauwelijks iets kost (d.w.z. 85 euro incl. verzendkosten voor 128GB). Ik heb nog nooit zo weinig geld voor een Plextor betaald... (anders gezegd: ik heb nog nooit een Plextor product gekocht omdat het zo duur was)

[Reactie gewijzigd op donderdag 20 juni 2013 14:56]


Door Tweakers user Bram1337, woensdag 26 juni 2013 01:23

Zijn de Intel 330/335/520 series ook hall of fame waardig?

De 330 zijn bijvoorbeeld een stuk goedkoper dan de 320 (nog steeds). Qua benchmarks (vooral 4k reads maar ook de rest) gingen die er op vooruit. Echter hebben ze een andere controller en minder lang garantie (en dus levensduur (write cycles)), waardoor ik je keuze voor de 320 series begrijp. Maar ik wil het toch vragen, want de gemiddelde consument zal toch ook naar de prijs kijken en niet zo snel aan het maximaal aantal write cycles komen verwacht ik.

De 520 schijnen qua architectuur gelijk te zijn aan de 330.

De 335 zijn net iets energiezuiniger dan de 330.

Verder vond ik je blogpost informatief en leuk om te lezen.

Door Tweakers user CiPHER, woensdag 26 juni 2013 01:33

520 is hetzelfde als de 330: beide Sandforce SSDs; de 520 heeft enkel beter NAND-geheugen. Beide SSDs zijn niet slecht maar ik zou ze zeker niet aanbevelen.

De Intel 320 is een échte Intel SSD met Intel controller. Dat is 180 graden anders dan dan de 330 en 520 series. De 320 heeft als enige Intel consumenten SSD de beschikking over power-safe capacitors en is dus inherent veilig terwijl de overige modellen dat niet zijn.

De enige Intel SSDs die interessant zijn om te overwegen, zijn die met een Intel controller. Dit betreft de X25-M (klassieker; misschien goedkoop 2e hands), de 320 (de meest betrouwbare consumenten SSD) en de nieuwe Intel S3500. Laatstgenoemde is echter officiëel geen consumenten SSD, maar is qua prijs zeker concurrerend met de Intel 320 series. Hij is vooral sneller omdat hij een nieuwere controllerchip heeft. Hij is echter op dit moment van schrijven nog niet/nauwelijks leverbaar.

Voor advies over de beste SSD zie ook mijn SSD best buy guide.

Door Tweakers user EricChang, dinsdag 13 augustus 2013 16:45

Dank voor dit uitstekende verhaal! Goed om te lezen dat er mensen zijn die nadenken over FLASH betrouwbaarheid.

Ik kan wel een kleine toevoeging aan de meer natuurkundige kant van dit topic.

Ten eerste: verwar FLASH niet met SSD. FLASH is een type SSD geheugen. Maar er zullen snel veel betere soorten komen (eind van deze post noem ik er eentje)

Ten tweede: FLASH slijt doordat het een erg hoge spanning gebruikt om electronen door een isolerend laagje in de floating gate te schieten (tunnelen). Deze hoge spanning is een groot probleem. Aangezien de roadmaps steeds lagere chipspanningen voorschrijven moet er steeds meer chip area besteedt worden aan 'spanningspompen'. Het woord FLASH benoemt al hoe het geheugen geschreven wordt: met een soort van electronenflits. Hier is dus niks aan te doen en kan ook niet bij een lagere spanning.
Het probleem ontstaat doordat hoge energie electronen het isolerende materiaal rondom de floating gate (meest oxide) kapot schiet. Dit is dus wel een soort mechanische slijtage, ook al is het op atoomniveau.
Nu weten de meesten van jullie waarschijnlijk wel dat oxide diktes afnemen als je naar kleinere nodes gaat (gebeurt ook bij gewone transistors, zonder floating gate). Dit betekent dat de boel sneller kapot gaat.
Een vervelende limiet voor FLASH is het aantal electronen op de floating gate. Dat wordt onderhand zo laag (tientallen!!) dat je het je bijna niet meer kan veroorloven dat er een paar ontsnappen door de oxide barriere die het al zo zwaar te verduren heeft.

Dit is in een notendop een vd grootste problemen van FLASH. En je raadt het al: het is verhaal zonder happy end. De heersende mening in de wetenschap is dat hier geen oplossing voor is. FLASH gaat nog een paar jaar kunnen schalen en dan is het voorbij :-(

Fabrikanten kijken nu bv naar 3D FLASH. De transistors worden niet kleiner, maar op elkaar gestapeld. Want uiteindelijk zijn we alleen maar geinteresseerd in hoeveel er in een doosje past, niet hoe het op de chip werkt.

Er zijn gelukkig ook (veel snellere, zuinigere, bit addressable, etc) alternatieven in de maak. Een goede kandidaat: Phase Change RAM.

Door Tweakers user kdekker, dinsdag 29 oktober 2013 12:04

Wordt dit topic nog bijgehouden? Ik zie geen/weinig informatie over recente SSDs. De veelgeroemde Crucial M500 wordt zo langzamerhand ook ouder. Zijn er in de rest van de SSD wereld geen interessante ontwikkelingen (Samsung EVO, anders?)

Door Tweakers user CiPHER, zondag 3 november 2013 16:26

@kdekker: ik denk dat je op de Best Buy Guide wilde reageren. Misschien kun je beter daar je reactie plaatsen. Samsung EVO vind ik op dit moment niet interessant genoeg om op te nemen in de BBG. Daarover is op het forum ook een keer discussie geweest. Hij kan mogelijk wel als alternatief goedkoopste SSD, dat zal ik nog eens bekijken. Maar deze discussie hoort niet in deze blogpost thuis, want hier gaat het om betrouwbaarheid. ;)

Reageren is niet meer mogelijk