Raspberry Pi, lifetime NAND flash

[TunderNerd]

Beste tweakers,

Ik ben trots eigenaar van de Raspberry Pi, en andere linux hardware. Naast dat ze allemaal linux draaien hebben ze nog een gemeenschappelijke deler: de kernel staat op NAND-flash.
Zoals julie weten gaat NAND flash langzaam maar zeker kapot. Aangezien fabrikanten hun gegevens / tests e.d. geheim houden / zeer beperkt geven / weinig van klopt is de levensduur slecht te voorspellen. En daarom ben ik er een "onderzoekje" naar gestart. Deel hier al je kennis over NAND! Zodat wij nog langer kunnen genieten van onze XBMC machine's / Automatische broodroosters / Licht bediening / gazonbesproeiing installaties.

Zoals eerder vermeld gaat NAND flash langzaam maar zeker stuk. Afhankelijk van het type is dit:
-SLC: 1 bit per cel, gemiddelde max. read/write: 10^5
-MLC: Meerdere bits per cel, gemiddelde max. read/write: 10^4

Er zijn verschillende truuks om je flash langer goed te houden. Het begint bij de aanschaf: een grotere, SLC kaart van een betrouwbaar merk(b.v. Sandisk) is altijd aan te raden. het juiste Filesystem is de duidelijke stap 2: Journaling filesystems zijn not done. De laatste ontwikkelingen komen van Samsung: f2fs. Dit komt helaas pas terug in linux 3.8(maar voor de echte tweaker is dat natuurlijk geen probleem).

Waarom (!meestal) geen Chinese ebay spullen?
Om je kaart zo lang mogelijk heel te houden, wil je alle cellen evenveel belasten. In de "duurdere" NAND kaarten zit een stukje MMU verstopt. data wordt contstand verplaatst, zodat alle cellen evenveel slijten. Kapotte delen worden niet meer gebruikt(Het is op cel niveau zeer goed te voorspellen wanneer de cel kapot gaat!). Hierdoor gaat data niet verloren, en blijven onze systemen werken. Niet alle kaarten hebben dit! Vooral de goedkoopste kaarten falen hierin. De betere merken hebben dit meestal wel: helaas worden algoritmes e.d. angstvallig stilhehouden(en daar wordt nou net leuk...)

Waarom een (te) grote kaart kopen?
Algorithmes in de SD-kaart verplaatsen contsand de data om zo de belasting van de cellen gelijk te houden. Een grotere kaart betekend meer mogelijkheden met verplaatsing. Hierdoor zal je kaart langer mee gaan.

Wanneer je een eigen log-programma (zoals het bijhouden van je aquariumtemperatuur) schrijft loont het om eerst je data in je RAM te verzamelen i.p.v. contstand je log op je SD-Card te schrijven. Elke schrijfactie wordt namelijk een compleet blok belast(2 of 4 Kb), en dit verhoogd de slijtage ontzettend. Een simpel te realiseren- maar zeer bruikbare tip!

tests
Natuurlijk wil je weten hoe zwaar je kaart belast wordt. Met iostat krijg je een log waar al deze informatie in terug te vinden is. het volgende commando geeft elke seconde een update:
iostat -x -d -k sda 1
De eerste meetwaarde is ovrigens onzin! Houd hier rekening mee wanneer je bijv. een shell script wilt schrijven die iostat zonder interval gebruikt. Dit geeft foutieve waardes! Ik kom met een Idle systeem op gemiddeld 8 Kb/s (heb hiervoor een progje geschreven. Mocht er intresse zijn kan ik hem eventueel posten).

Met dit gegeven is de levensduur van de kaart (zeer grof) te berekenen. de volgende formule kan hiervoor gebruikt worden:

levensduur(dagen) = (A*L / 3600 RW) / T
A: grootte van vrije ruimte SD-kaart (in Kb)
L: levensduur cel flash (meestal 10^4 of 10^5)
RW: Read + Write acties per seconde (in Kb)
T: aantal uur aan per dag

Het probleem met deze formule:
1. Schrijven is slechter voor NAND flash dan lezen, hier wordt geen rekening mee gehouden
2. Het opstarten wordt niet meegerekend (en ik heb nog geen idee om dit uit te zoeken)
3. Levensduur van cellen is behoorlijk grof.
4. er wordt alleen rekening gehouden met vrije cellen(spare): de formule geeft eigelijk weer wanneer de spare cellen op zijn en houd geen rekening met de grootte van de data

Dus...
Zoals julie kunnen lezen heb ik niet stil gezeten. Ik ben vooral benieuwd naar:
1. Wat zijn julie ervaringen (Merk, levensduur, omstandigheden)
2. Welke tips hebben julie voor mij?
3. Wat is de verwachte levensduur van julie kaarten? (volgens de eerder genoemde formule)
4. Hebben julie betere manieren / verbeteringen voor mij(uitbereiding formule, teststrategieën, mischien al tests gedaan)?

Overige bronnen

http://www.google.nl/url?...bv.44770516,d.dmQ&cad=rja : zeer intresante PDF waar verschillende kaarten worden getest
http://serverfault.com/qu...r-hard-disk-load-on-linux : over iostat.

Thanks!

TunderNerd

[LauPro]

Ik weet dat C'T al enige jaren SSD's aan het testen is met random writes om te kijken of de performance af neemt. En dit schijnt allemaal best wel mee te vallen. Zelfs met 24/7 intensief SSD's te belasten ziten de meeste merken gewoon goed. Ik heb het tijdsschrift niet meer maar het laatste artikel hierover verbaasde mij enorm.

En eigenlijk is dat ook niet zo gek. Elke fabrikant die dergelijke chips produceert zal een uitgebreid testsysteem ontwikkelen om zeker te zijn dat de chips zich houden aan de garantieperiode. Als klanten na 6 maanden al terugkomen met kapotte chips dan gaat je reputatie snel naar de knoppen.

Dit in combinatie met Linux waar je distributies en ook geoptimaliseerde filesystems hebt die al zeer weinig writes doen kan een simpele kaart makkelijk 5-10 jaar mee gaan. Om helemaal zeker te zijn zou ik altijd een kwaliteitskaartje erin doen en geen Chinese nepvariant. En waarom zou je, een simpele 4 GB FlashDisk heb je al voor onder de 10 euro. Voor iets belangrijks als dataopslag zou ik niet gaan bezuinigen.

Ik ben momenteel de Raspberry aan het testen bij een lichtinstallatie welke 6 maanden in een museum hangt. Hiervoor had ik altijd industriële computertjes welke duur zijn en waar in de praktijk ook van blijkt dat een moederbord kapot kan gaan (been there done that). Het idee is dan blijkbaar dat je allemaal dure servicecontracten neemt om deze hardware te supporten. En om nou allemaal server grade hardware neer te zetten met redundate voedingen lijkt mij wat overkill voor de toepassing. Less is more wat dat betreft. Qua rekenkracht heb ik niet veel nodig maar ik wil niet het wiel opnieuw gaan uitvinden.

Dan heb ik liever een systeem waar bij een defect de gehele 'computer' kan worden vervangen, kost bij wijze van spreken 50 euro extra aan een behuizing en Raspberry+sd maar dat scheelt mij weer een ritje. Maar dit is een beetje off topic.

Er zijn op internet meerdere mensen geweest die Flash write endurance tests hebben gedaan. De grootste factor is wel dat je eigenlijk het geheugen moet gebruiken of je raakt het kwijt (use it of loose it). Wat dat betreft spreekt dat alle beweringen om zo min mogelijk writes te doen tegen.

Het geheugen is ingedeeld in blocks en per block heb je de registers waar de data daadwerkelijk in staat. Vergelijk deze registers met 'kleine batterijen', na verloop van tijd loopt de spanning terug en zo kan een logische 1 een 0 worden, dat noemen we corruptie. Om dit te voorkomen zou je periodiek alle registers opnieuw moeten programmeren zodat de spanning weer netjes op niveau komt.

Deels wordt dit voorkomen doordat het geheugen in blocks is ingedeeld en bij het schrijven naar een block dit hele block wordt herschreven. Dit heeft als voordeel dat je een betere garantie hebt dat de data is dat block valide is, tegelijk krijg je veel meer writes/cycles dan je in eerste instantie denkt.

In principe is de huidige levensduur van Flash ergens rond de 10 jaar maximaal (zeg 5 jaar zeker). Je zou deze kaarten makkelijk 20 of 30 jaar kunnen gebruiken mits je bijvoorbeeld elk jaar even alle blocks opnieuw programmeert. Ik weet niet of deze ondersteuning al in de Linux kernel zit maar het zou een leuke feature zijn.

Het is dus een compromie tussen levensduur en integriteit van je data. Als je gebruik maakt van een logging module is het beter om bijvoorbeeld deze logs op tmpfs te zetten en dan een logdeamon te gebruiken die bijvoorbeeld elk uur of elke dag deze flusht naar de NAND Flash. Het nadeel hiervan is wel dat bij spanningsverlies een deel van je log weg is. Maar niet alle data is klein genoeg om per uur of per 24 uur weg te schrijven.

Het zijn dus een hoop factoren maar voor een simpele doorsnee Raspberry Pi die 24/7 draait met minimale disk i/o zou ik zeggen dat je zeker 5 jaar met 1 kaartje moet kunnen doen.