SSD: hoe veilig is je data?

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

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.