SSD: hoe veilig is je data?

Door H!GHGuY op maandag 24 december 2012 09:46 - Reacties (14)
Categorie: -, Views: 5.772

Bij SSDs denkt iedereen meteen aan snelle en dure hard-disk vervangers. Pralines in plaats van confituur tussen je boterham. Volgens een recente poll wil bijna 10% van de tweakers een SSD onder de kerstboom. Maar hoe veilig is je data op zo'n SSD?

Edit:
Ik edit niet graag een blogitem, maar naar aanleiding van de vele comments duw ik er dit en een kleine update in de conclusie toch maar even tussen:
In het onderstaande stukje bekijk ik enkel een aantal punten waarop het met SSDs op technologisch vlak kan misgaan. Ik hou geen rekening met de kans waarmee het mis kan gaan.

Firmware bugs


Solid state drive zijn eigenlijk mini-computers. Dit kan je best zien op volgen diagram van Texas Instruments:
http://www.ti.com/graphics/blockdiagram/blockdiagram_images/6260.gif

Waar het blokje CPU staat, bedoelen ze ook echt CPU. Veelal gaat het over een ARM-core, soms zelf multi-core, waar de nodige periferie in een SoC gebundeld is.
Aangezien het een 'generieke' CPU core is, draait er dan ook gewoon software op. Meestal een RTOS met daarboven de SSD-specifieke applicatie.

En om tot het punt te komen: alle software bevat bugs. Als developer doet het me zelfs geen pijn om dit te moeten toegeven. Nog nooit een verdwaalde rozijn in een wit brood gevonden? Of een slak op een krop sla?

Er zijn wel enkele gekende voorbeelden zoals de befaamde 8MB bug van Intel, de verdwijnende Corsair drives, etc. Zoek maar eens op de termen "SSD firmware bug".

De impact van deze bugs kan gaan van verlies van data tot data corruptie en zelfs tot dode drives.

Niet naleven van ATA commando's


Voor dit stukje moet ik even wat dieper graven in hoe filesystems werken en dan vooral over de functie van een journal.

Een journal beschrijft eigenlijk wat de volgende actie op de drive is, bvb bij het verwijderen van een file:
• Markeer dat file X zal verwijderd worden in de journal
• Verwijder file X

Deze journal staat ook gewoon in een aparte stukje in het filesystem. Er zijn verschillende soorten journalling waar ik nu verder niet op inga. Belangrijk is om te weten dat journalling, om correct te werken een garantie moet krijgen van de drive waarop gewerkt wordt. De drive moet het commando om de cache leeg te maken correct verwerken.

Tussen het schrijven naar de journal en het effectief uitvoeren van de actie wordt namelijk typisch zo'n commando naar de drive gestuurd. Dit zorgt ervoor dat de journal effectief op de flash geschreven is vooraleer overgegaan wordt tot het effectief uitvoeren van die actie.

Bij bovenstaand voorbeeld, veronderstellend dat de drive alles zo lang mogelijk in cache houdt:
ActieWat gebeurt er bij stroomuitval
(nog niets gebeurd)Niets. Het bestand is niet verwijderd
Markeren in de journalNiets. De journal entry staat niet op disk
(markering zit in drive cache)Niets. De journal entry staat nog niet op disk.
Cache leegmaken
(journal staat op disk)File wordt verwijderd na reboot
Verwijder fileFile wordt verwijderd na reboot
(verwijderde file zit in drive cache)File wordt verwijderd na reboot
(effectief wegschrijven naar disk)
(alles staat op de drive)File is verwijderd. Journal entry wordt genegeerd.


Je ziet dat er veel punten zijn waar het kan misgaan. Ik heb trouwens het stukje cache leegmaken zelf overgeslaan, daar komen we later op terug.

Ik haalde het hierboven al aan: het filesystem leeft op de garantie dat de drive het commando voor het leegmaken van de cache naleeft. Helaas is dit niet altijd het geval, in de naam der performantie en levensduur.

Er zijn enkele redenen waarom drives veel data in de cache houden:
• Er is een (kleine) kans dat de data kort erna opnieuw overschreven wordt. Niet wegschrijven naar disk betekent dus dat je een kostbare erase-cycle uitspaart wat de levensduur van de drive ten goede komt.
• Hoe meer data een drive in de cache heeft, hoe beter de wear-leveling van de drive zijn werk kan doen. Opnieuw komt dit de levensduur van de drive ten goede.
• Schrijven naar de cache is sneller dan schrijven naar het flash-geheugen. Met een reusachtige cache van 512MB kun je behoorlijk veel bufferen aan zeer hoge snelheid.

Ik kan al raden wat zo'n SSD met 512MB cache doet als z'n cache voor de helft vol zit en er een "FLUSH CACHE" commando aankomt. Die kijkt even of niemand hem ziet en veegt het commando nadien gewoon lekker onder de mat.

Uit ervaring weet ik dat sommige sandforce drives ook gewoon dit commando negeren om dan zelf elke 2 seconden de cache leeg te maken. Helaas is dit niet voldoende. Het punt waarop de drive de data wegschrijft is niet het punt waarop het filesystem dit wil. Je hebt dus geen enkele garantie dat je data bij stroomuitval correct is.

SLC, MLC, TLC en ECC


Een hele hoop acroniemen om te vertellen dat flash-geheugen foutgevoelig is. Ik zal de gedetailleerde werking van een SSD besparen, zie daarvoor dit uitstekende artikel.

Er zijn enkele zaken toch belangrijk om te vermelden. NAND flash bewaart zijn data door electronen op te slaan in kleine cellen. Wanneer je data leest, dan kijk je eigenlijk hoeveel lading er in een cel zit. Voor SLC (single level cell) heb je maar 2 niveau's: 0 en 1. Voor de meeste MLC heb je er 4 en nu is er zelfs TLC met 8 niveau's.

Bij 8 niveau's gaat het over zeer kleine verschillen in lading. Er kunnen dus veel meer foute bits zijn bij het uitlezen. Dan laten we het verschil in aantal wis-cyclussen (en dus de levensduur van je drive) nog achterwege.
Bitfouten zijn niet plezant. Het gaat namelijk over corrupte data. Een NAND flash komt trouwens af fabriek met veel kapotte cellen. Niet erg, want er bestaat zoiets als ECC, error correcting code.

Van NAND flash specifieert de fabrikant telkens hoeveel bitfouten je mag verwachten. Typische getallen waren vroeger 1bit/256byte, die met standaard Hamming codes konden opgelost worden. Nu gaat het over veel grotere getallen van 4bit/512byte. Ik dacht trouwens al ergens 16bit per 512byte te hebben zien passeren... Hiervoor moeten zwaardere algoritmes zoals Reed-Solomon en BCH gebruikt worden.

Soms wordt het toch echter teveel en kunnen zelfs die kunstjes je data niet redden.
Meestal houdt een SSD controller bovendien bij het uitlezen rekening met het aantal fouten dat gecorrigeerd wordt en als dit oploopt, wordt het blok geheugen als slecht gemarkeerd zodat het niet meer gebruikt wordt. Dit voorkomt meestal tijdig dat je data verloren gaat, maar soms ook niet.

De eerlijkheid gebiedt me hier om te zeggen dat ook gewone harde schijven ECC nodig hebben.
Weet je nog de overstap naar sectoren van 4KB? 1 van de redenen is dat ECC dan over grotere blokken kan uitgerekend worden en er dus iets minder overhead is. Op zich is hier dus weinig verschil met harde schijven.

Interne huishouding


Er is nog iets wat je over NAND flash moet weten. Een conventionele harde schijf is ingedeeld in sectoren van 512bytes, of sinds recent 4KB. No magic. Gewoon een hoop sectoren achter elkaar.
NAND flash wordt anders ingedeeld, op volgorde van groot naar klein:
• Erase blocks. De kleinste eenheid waarmee flash gewist kan worden (bvb 128KB)
• Pages. De kleinste eenheid waarmee flash geschreven en gelezen kan worden. (bvb 2KB)
• Cellen. Slaan individuele bits, of groepen van bits op.

Elke NAND flash specifieert een gemiddeld aantal erase-cycles per erase-block. Voor SLC gaat dit over een 100000, eMLC doet er 30000, bij MLC gaat het afhankelijk van het type over een 10000, 5000 of 3000 en voor TLC spreekt men over een duizendtal. Telkens je dus een erase block wist wordt hij een 'jaartje ouder'. Om in diezelfde metafoor te blijven: je kan dus maar beter profiteren van wat het leven je te bieden heeft.

Aangezien je NAND flash leest en schrijft in blokken die enkele grootteorden kleiner zijn dan een erase block moet er wear-leveling toegepast worden. Er zijn veel trucs die ze kunnen toepassen, maar die zijn hier nu even niet van belang.
Wat wel van belang is, is dat hier een hele boekhouding bij komt kijken en dat de drive terwijl jij denkt dat ie uit z'n neus zit te vreten, eigenlijk bezig is om ervoor te zorgen dat ie langer meegaat en ook snel blijft. Er wordt dus gelezen en geschreven op momenten dat je het niet verwacht.

Bovendien houdt een flash nog heel veel metadata bij (bvb het aantal keren dat een blok geschreven/gewist is geweest, een mapping van sector naar een pagina in NAND flash, etc.)
Hierbij komen we dus ook nog even terug op wat er gebeurd als de drive zijn cache leegmaakt. Op dit moment moeten bvb die mappings bijgewerkt worden. Als dit incorrect gebeurt, dan raken files corrupt. Je kan dan bijvoorbeeld plots data van de ene file in een andere terugvinden. Echt gebeurd! Eigenlijk komt dit overeen met wat er kan gebeuren op een filesystem zonder journaling of incorrecte journaling door een ontbrekend flush cache-commando.

Als de stroom op zo'n moment dus uitvalt, kun je maar hopen dat de firmware in je drive goed voor je data zorgt... Helaas vind je over dit soort failures geen statistieken; wat je niet ziet, ...

Stroomuitval bij programmeren van MLC/TLC


Tot slot, iets wat ik ook pas recent heb ontdekt en waar je nog maar weinig informatie over vindt...
Bij MLC kun je meerdere bits opslaan per cel. Fabrikanten verminderen het aantal cellen die ze groeperen tot pages niet, aangezien dit meer plaats op de chip zou vereisen. Dus eigenlijk kun je per fysieke page, meer data kwijt. Vermoedelijk laten ze de grootte van een logische page niet meegroeien voor andere redenen zoals ECC correctie. In plaats daarvan organiseren ze een fysiche page in logische pages.

Ik hoor je al denken: maar dan moet je telkens wissen als je 1 van de logische pages wil schrijven! Dit is echter niet waar. Je kan een page meerdere keren beschrijven tussen 2 erases.
En hier komt het addertje... Als je de 'upper' page beschrijft en de stroom valt uit, dan is er een grote kans dat je ook de 'lower' page corrupt maakt. Dit fenomeen heet "lower page corruption" en komt enkel voor bij MLC en TLC. Bij TLC is het probleem trouwens nog erger aangezien je nog meer data corrupt maakt.

Conclusie


Veel van de beschreven problemen kunnen verholpen worden door ofwel het gebruik van een drive met supercap (of gelijkwaardig) zoals de Intel 310 en 710 reeksen of door het gebruik van een UPS.

De andere problemen hangen af van de kwaliteit en het type van het flash-geheugen en de kwaliteit van de firmware in de drives. Kan iemand me nog vertellen waarom Intel zijn eigen firmware schreef voor zijn drives met SandForce controller? Het was niet omdat ze geld over hadden... Ik herinner me nog een tweakblog waar de auteur het aantal RMAs per merk en drive in grafiekjes goot. Wordt het een en ander al duidelijk?

Mijn persoonlijke ervaringen stemmen me bovendien pessimistisch. Het gros van de fabrikanten lijkt performance en levensduur van een drive ver boven de veiligheid van die data te stellen. En eerlijk: wat heeft het een supersnelle drive die 10jaar mee gaat van zin als de data erop bij het minste ongeluk corrupt kan worden?

Edit:
Naar aanleiding van de comments hier toch ook even een nuancering. Mijn zorg is niet dat SSDs kapot kunnen gaan. Big deal, ik heb ook al menig HDD versleten. Mijn zorg is wel dat fabrikanten performance en endurance boven reliability stellen. Er zijn enkele trade-offs mogelijk in het H/W design en in de firmware en het lijkt er sterk op dat alle vendors deze trade-offs steevast naar performance laten overhellen, want dat staat goed in de benchmarks en heeft dus direct gevolg op de verkoop. Anderzijds berichten de media (hier vooral magazines en websites) enkel en alleen over performance en (theoretische) endurance. Er worden geen testen gedaan op reliability, hoewel dit niet zo ingewikkeld hoeft te zijn.

Volgende: Tweakers gezeur 01-'13 Tweakers gezeur
Volgende: MBTI - Wie ben ik? 11-'12 MBTI - Wie ben ik?

Reacties


Door Tweakers user mux, maandag 24 december 2012 12:59

Maar je valt nu in twee superstandaard beginner's traps op het gebied van SSDs (en zoveel andere 'nieuwe' techniek): kwalitatieve argumenten en eenzijdige beschouwing.

Door kwalitatief ipv kwantitatief te kijken maak je jezelf bang met risicofactoren zonder een idee te hebben van de werkelijke risico's (voorbeeld: 'er kan zomaar uit het niets een meteoriet op je hoofd terecht komen!' (kwalitatief) in plaats van 'er is een kans van 0,00000000000000000001% dat er een meteoriet op je hoofd dondert' (kwantitatief)). Dit is het bodyscan-effect: puur en alleen door de aandacht erop te vestigen worden statistisch onbelangrijke risico's beschouwd als grote risico's.

Tweede punt: eenzijdige beschouwing: SSDs hebben failure modes. En HDDs dan? En RAM dan? En papier dan? Allemaal hebben ze even ernstige total failure modes. Natuurlijk, het zijn allemaal fysieke dingen, alles kan stuk, alle data is een vorm van lage entropie die niks liever wil dan stukgaan. De vraag is niet wat voor problemen er zijn met SSDs, de vraag is hoe belangrijk deze problemen zijn in een specifieke toepassing vergeleken met andere datadragers. Geloof het of niet: datacorruptie is een idioot groot probleem bij HDDs, tot op het punt dat je HDD geen sector correct van de schijf kan lezen. Zonder de geavanceerde, toepassingsgerichte foutcorrectiealgoritmen die hdd-controllerfabrikanten hebben ontwikkeld zouden moderne 100+GB HDDs onmogelijk te gebruiken zijn. HDDs hebben een heel hoge incidentie van total failure: de gedachte dat je data op een SSD weg is bij disk failure terwijl op een HDD de data nog enigszins aanwezig is, is niet waar. En wat dacht je van RAM? Alle gebruikersdata die je leest komt in RAM te staan, en alle data die je naar een SSD of HDD schrijft komt uit het RAM. Volgens Microsoft is een significant deel van BSODs vandaag de dag de oorzaak van point failures in RAM en I/O errors in systeembussen. Zelfs zonder dat je SSD of HDD iets fout heeft gedaan kan je data heel goed al corrupt zijn voordat je het wegschrijft.

SSDs zijn kwantitatief niet slechter of beter dan HDDs, zeker niet als je failure data normaliseert naar I/Os (MB of IOPS). Afhankelijk van welk merk je te pakken hebt kan een SSD extreem goed presteren (Intel SSD 7xx) of slechter dan alles behalve de Maxtor Diamondmax 10 (OCZ Sandforce 1e/1.5e generatie).

Het is helemaal waar dat SSDs alle failure modes hebben die jij aangeeft, dat het jonge technologie is die zeker bij een aantal specifieke fabrikanten een aantal keren keihard op z'n bek is gegaan, maar dat wil niet zeggen dat SSDs ongeschikt zijn als datadrager - integendeel. Het is the way forward. We lopen tegen de limieten aan van wat we met magnetische opslag kunnen doen, en de rek is nog lang niet uit silicium opslag. Nu zijn het nog nicheproducten door hun hoge prijs per GB maar binnenkort zullen ze ook de plek van bulkopslag innemen.

Door Tweakers user VantageR, maandag 24 december 2012 13:15

Mooi stukje, wat ik als (relatieve) leek goed kan volgen. De reden dat fabrikanten de performance boven de veiligheid van de data verkiezen, lijkt me dat SSD's nu nog enkel gebruikt worden om het besturingssysteem en andere software te draaien. Hierbij is het verliezen van data minder erg dan wanneer het puur voor dataopslag gebruikt wordt.

Wel zie je steeds vaker bij laptops dat er alleen een SSD inzit, vanwege de snelheidswinst en het ontbreken van bewegende delen. Echter heeft een laptop natuurlijk een backup voor stroomuitval in de vorm van een accu. Zelf heb ik ook een SSD in m'n laptop geplaatst en ik maak heel regelmatig backups, dus de risico's lijken me dan wel minimaal.

Door Tweakers user H!GHGuY, maandag 24 december 2012 13:19

Juist, ik focus me niet op incidence rates. Het ging me puur over enkele van de problemen die SSDs op technologisch vlak kennen. Het gaat tenslotte over relatief nieuwe technologie, waar HDDs al best lang meegaan.

Al kan ik daarover wel kwijt dat incidence rates van bepaalde failure modes die bij power cycles kunnen gebeuren best schrikwekkend hoog zijn, zeker wanneer je ze uitsmeert over het aantal drives die je in gebruik hebt. Ik ben op dit moment betrokken bij power cycle tests op 2 merken enterprise SSDs en de issues die met die 2 drives al zijn bovengekomen tonen voor mij aan dat een SSD enkele problemen heeft mbt power failure die een gewone HDD niet heeft. De eerlijkheid gebiedt me wel op hierbij te vermelden dat het wel over een iets ouder type controller gaat.
De opvolger van die controller voegt een power-failure circuit toe wat de reliability wel ten goede zou moeten komen.

Verder hebben we voor HDDs RAID uitgevonden. En hebben we filesystems en andere software afgestemd op hoe een HDD werkt. Voor SSDs zijn we nog zo ver niet.

Bovendien zijn SSDs niet "de way-forward", het is gewoon een technologie die zijn tijd zal meegaan. Er wordt volop gewerkt aan nieuwe technieken (post-CMOS memories). Flash geheugen loopt tegen zijn limieten aan qua fysieke grootte en zal dus vroeg of laat vervangen worden.
VantageR schreef op maandag 24 december 2012 @ 13:15:
Mooi stukje, wat ik als (relatieve) leek goed kan volgen. De reden dat fabrikanten de performance boven de veiligheid van de data verkiezen, lijkt me dat SSD's nu nog enkel gebruikt worden om het besturingssysteem en andere software te draaien. Hierbij is het verliezen van data minder erg dan wanneer het puur voor dataopslag gebruikt wordt.
Verliezen van data is helaas nooit prettig. Fabrikanten rekenen er trouwens helemaal niet op dat jij enkel je OS en software op zo'n SSD zet. Voor hen gaat het over "user"-data; niets meer, niets minder. Jouw stelling gaat trouwens vooral op voor de consumentenmarkt. Voor enterprise is dit helemaal niet waar.

[Reactie gewijzigd op maandag 24 december 2012 14:01]


Door Tweakers user warhamstr, maandag 24 december 2012 15:08

Data? Op een SSD?? Dan ben je sowieso niet slim bezig?

Door Tweakers user Damic, maandag 24 december 2012 15:42

warhamstr schreef op maandag 24 december 2012 @ 15:08:
Data? Op een SSD?? Dan ben je sowieso niet slim bezig?
Er staat ALTIJD data op en ssd/hdd, je OS en programma's enzo dat is ook data. Weliswaar minder erg als dat weg gaat, maar dan nog.

Door Tweakers user Hakker, maandag 24 december 2012 21:06

Misschien moet je er ook maar eens bij vermelden hoeveel van het artikel ook voor HDD's geldt want HDD's doen niet veel anders en ook daar zijn bv genoeg fimware bugs.
het domweg slecht uitvoeren van commandos. Zelfs simpele punten als bv het idle parking van een drive zorgt al voor genoeg problemen.

[Reactie gewijzigd op maandag 24 december 2012 21:09]


Door Tweakers user analog_, maandag 24 december 2012 22:32

Met hakker, alle problemen die je boven beschrijft bestaan ook op harde schijven met de extra risico's van bewegende mechaniek en dat sommige problemen (supercap) technisch niet realiseerbaar zijn voor conventionele harde schijven.

Je kan overigens veel problemen aanpakken in je filesystem/volume manager (zoals je zelf al zei, raid). Als je het verhaal nog enger wilt maken moet je Reliability Analysis of ZFS (Asim Kadav, Abhishek Rajimwale) eens lezen. ZFS is uiteindelijk ook niet 100% secure, maar wel een flink stuk meer dan alle andere filesystems.

[Reactie gewijzigd op maandag 24 december 2012 22:33]


Door Tweakers user H!GHGuY, dinsdag 25 december 2012 09:20

Hakker schreef op maandag 24 december 2012 @ 21:06:
Misschien moet je er ook maar eens bij vermelden hoeveel van het artikel ook voor HDD's geldt want HDD's doen niet veel anders en ook daar zijn bv genoeg fimware bugs.
het domweg slecht uitvoeren van commandos. Zelfs simpele punten als bv het idle parking van een drive zorgt al voor genoeg problemen.
Alle problemen die inherent zijn aan flash-geheugen mist een HDD natuurlijk. Anderzijds Hebben ze inderdaad de mechanische problematiek. Aligneren/parkeren van koppen, schokbestendigheid, etc. Het is een compleet ander probleemdomein, waar ik niet in thuis ben.

Anderzijds kun je zeggen dat de technologische vooruitgang in HDDs op het vlak van electronica/firmware tergend traag is gegaan. Zie hier voor een overzicht. De overgang van PIO naar UDMA, TCQ en NCQ, etc.
Natuurlijk is dit ingegeven door het feit dat HDDs ook maar langzaam hun grenzen verlegden qua snelheid. Waarom veel tijd investeren in firmware schrijven als je dan alsnog quasi 8-10ms moet wachten eer de leeskoppen gealigneerd zijn? Het leverde gewoon niet op.
Het is maar sinds ATA-4 dat we TCQ kennen. Vanaf dan konden drives de requests ordenen en mbv een elevator algoritme of iets gelijkaardigs proberen om de bewegingen van de koppen te minimaliseren.
analog_ schreef op maandag 24 december 2012 @ 22:32:
Met hakker, alle problemen die je boven beschrijft bestaan ook op harde schijven met de extra risico's van bewegende mechaniek en dat sommige problemen (supercap) technisch niet realiseerbaar zijn voor conventionele harde schijven.
Harde schijven zijn op dat vlak enkel bezig om bij power loss hun koppen zo snel mogelijk te parkeren. De rest interesseert niet, lijkt me ;)
Je kan overigens veel problemen aanpakken in je filesystem/volume manager (zoals je zelf al zei, raid). Als je het verhaal nog enger wilt maken moet je Reliability Analysis of ZFS (Asim Kadav, Abhishek Rajimwale) eens lezen. ZFS is uiteindelijk ook niet 100% secure, maar wel een flink stuk meer dan alle andere filesystems.
ZFS is inderdaad een beer van een filesystem, maar draait wel best op een degelijk uitgevoerde machine waardoor het voor gewoon desktop of zelfs embedded gebruik toch wel afvalt.
De reliability features zijn wel om U tegen zeggen: over checksumming van data en metadata alleen al zouden we allemaal laaiend enthousiast moeten zijn!

Door Tweakers user Hakker, dinsdag 25 december 2012 16:44

Mijn punt is dat je conclusie hoewel deels waar veel te pessimistisch is. Uit jouw conclusie is alleen maar op te maken van gebruik een SSD niet want het is gewoon niet veilig.

Hou het eens in het daglicht tegenover andere media en dan zie je dat SSDs gewoonweg veiliger te gebruiken is dan andere media als optische opslag, HDD's zelfs spul als DAT heeft meer dan genoeg nadelen. Daarnaast gebruik je voor enterprise opslag zowieso al geen spul als een OCZ Vertex/Agility of een Intel 320.

Dan nog dien je altijd een goeie FS te gebruiken. en met bv ZFS bouw je wel meer zekerheid erin tuurlijk, maar introduceerd ook nieuwe problemen als mogelijke corruptie met het wegschrijven van data wat eerst in het geheugen gebeurt en dan pas naar de schijf in kwestie. Het gedeelte van geheugen naar schijven kan je grotendeels opvangen met ECC geheugen maar de stap daarvoor blijft een probleem.

Ja je praat dan over minieme waardes, maar daar gaat dit artikel ook over. Uiteindelijk is dus altijd de conclusie het maakt niet uit wat je doet het is nooit 100% veilig. Het enige wat men kan doen is het veiliger maken en als we dat in acht nemend zijn zelfs consumenten SSDs al veiliger dan enterprise HDDs.

Door Tweakers user H!GHGuY, dinsdag 25 december 2012 17:10

Hakker schreef op dinsdag 25 december 2012 @ 16:44:
Mijn punt is dat je conclusie hoewel deels waar veel te pessimistisch is. Uit jouw conclusie is alleen maar op te maken van gebruik een SSD niet want het is gewoon niet veilig.
Nee hoor, ik heb zelf ook een SSD in mijn PC; Niets mis mee.
Deze blog is vooral een reactie op 2 zaken:
- Reviews en andere richten zich enkel en alleen op performance en theoretische lifetime.
Nergens lijkt iemand bezig te zijn met reliability. Nochtans zijn de meeste genoemde failures niet zo moeilijk om uit te voeren.
- Wanneer je iemand vertelt dat een harde schijf een roterend medium is met koppen die zich op een afstand bevinden die kleiner is dan de dikte van een haar dan begrijpt iedereen dat er vanalles kan mislopen. Een harde schijf crash wordt dan ook sneller 'aanvaard'. Als je dan uitlegt dat een SSD niet meer is dan wat chips dan lijkt iedereen plots overtuigd dat er helemaal niets mis kan gaan. Alsof de stelling "mijn PC heeft in Excel nog nooit een rekenfout gemaakt" (overigens niet helemaal juist, voor de kenners) plots ook betekent dat een SSD geen failure modes kent.

Ik wou met dit blogje dus vooral de nadruk leggen op het feit dat SSDs (behalve firmware issues) geen heilige graal van reliability zijn, een perceptie die ik soms wel tegenkom.
Ik wou helemaal niet SSDs afraden of een volledige FMEA uitvoeren, inclusief incidence rates, maar gewoon vanuit technisch standpunt even enkele failure modes van een SSD belichten.
Hou het eens in het daglicht tegenover andere media en dan zie je dat SSDs gewoonweg veiliger te gebruiken is dan andere media als optische opslag, HDD's zelfs spul als DAT heeft meer dan genoeg nadelen. Daarnaast gebruik je voor enterprise opslag zowieso al geen spul als een OCZ Vertex/Agility of een Intel 320.
Helaas is mijn (beperkte) ervaring met enterprise drives dat ze gewoon dezelfde problemen hebben als hun consumer-grade tegenhangers. 2 manufacterers verkopen exact hetzelfde reference design met exact dezelfde firmware (op enkele config-opties na misschien). Dit doet me vermoeden dat ze ook niet meer doen als dezelfde firmware van de controller-vendor gebruiken net zoals alle consumer-grade drives.

De verschillen zullen hem wel zitten in de iets conservatievere settings van de firmware en misschien ook enkele andere lifetime-verbeterende opties (write-throttling anyone?).
Dan nog dien je altijd een goeie FS te gebruiken. en met bv ZFS bouw je wel meer zekerheid erin tuurlijk, maar introduceerd ook nieuwe problemen als mogelijke corruptie met het wegschrijven van data wat eerst in het geheugen gebeurt en dan pas naar de schijf in kwestie. Het gedeelte van geheugen naar schijven kan je grotendeels opvangen met ECC geheugen maar de stap daarvoor blijft een probleem.
In embedded en desktop is ZFS niet echt een optie. Bovendien kun je als fabrikant van devices geen ZFS shippen op Linux wegens license incompatibility. Als storage niet je core business is, is ZFS niet echt een compelling argument om naar Solaris of een BSD over te schakelen.
Ja je praat dan over minieme waardes, maar daar gaat dit artikel ook over. Uiteindelijk is dus altijd de conclusie het maakt niet uit wat je doet het is nooit 100% veilig. Het enige wat men kan doen is het veiliger maken en als we dat in acht nemend zijn zelfs consumenten SSDs al veiliger dan enterprise HDDs.
Daarvoor moet je incidence rates meetellen. Die heb ik gewoon niet. Dus over 'veiliger dan' doe ik geen uitspraken. Mocht jij wel zo'n getallen hebben dan ware het interessant om deze (waar mogelijk) te delen met ons.

Door Tweakers user Battle Bunny, woensdag 26 december 2012 20:33

Leuk stuk om te lezen. Ik vind mezelf geen beginner op deze gebieden, maar kwam toch veel nieuwe informatie tegen.

Inderdaad lijkt het aan het begin alsof je SSDs puur aan het afkraken bent. Het nuanceren wat je in de comments doet is prettig, en zou niet misstaan als begin van je artikel.

Door Tweakers user analog_, donderdag 27 december 2012 06:15

Je schrijft alle oplossingen pessimistisch af terwijl het allemaal methodes zijn die het geheel betrouwbaarder maakt dan 'de norm', ext4, ntfs op een harde schijf.

Simpel gezegd, kan er het volgende fout gaan:
  • hardware
  • HDD: draaiende delen + vitale elektronica
  • SSD: vitale elektronica
  • software
  • HDD: firmware disk
  • SSD: firmware disk
  • misc
  • SSD: supercap, performance
  • HDD: longer life time
Nu kan je daar wat kans percentages aan hangen en de boel even uitrekenen maar netto en zeker in RAID configs lijkt mij dit geheel opgevangen. Omdat SSDs kleiner zijn en sneller schrijven, rebuilden ze sneller en stijgt het overlevingskans significant tegenover disk arrays. Een vier disk RAID6 SSD array is met gemak betrouwbaarder dan een vier disk RAID10 of 5 SAS volume. SAS disks zijn het enterprise alternatief voor SSDs dus dat is de bottom-line keuze. Heck, je zou zelfs RAID-Z3 kunnen draaien of iets dergelijks wat nog meer betrouwbaarheid biedt. SSDs zullen dan nog SAS disks outperformen.

De enige echte killer is dat alle ssds spontaan overlijden, de vraag is of dat vaker voorkomt dan bij harde schijven (of de kans dat een SAS array spontaan dermate kapot is dat het verloren is tov. dezelfde kans met een SSD array). <insert verhaal raid is no backup>

[Reactie gewijzigd op donderdag 27 december 2012 06:15]


Door Tweakers user Pino Blauw, vrijdag 28 december 2012 00:55

hoe kan ik aan de specificaties van een ssd zien of hij supercap / UPS heeft? (heb het gegoogeld maar werd er niet wijzer van)

Door Tweakers user H!GHGuY, vrijdag 28 december 2012 08:12

Een UPS is een extern toestel. Je sluit er de stroomverbinding van je PC op aan en meestal ook nog een USB of andere verbinding waarlangs de UPS met je PC kan praten om te zeggen of de stroom is uitgevallen danwel hoe vol de batterijen nog zijn.

Intel noemt het bijvoorbeeld 'Enhanced Power Loss Data Protection' op zijn 320 series.
Verwacht je er maar aan dat elke vendor er een eigen marketing term voor verzint ;)

Reageren is niet meer mogelijk