Ik zocht gewoon binnen zijn prijsklasse naar iets met ECC wat ook de uitbreidingsmogelijkheden heeft qua SATA en nog andere leukere extra's zodat hij uiteindelijk meer haalde uit zijn budget. Slechts twee schijfjes is vanwege de ingebouwde voeding; je kunt denk ik alle 4 onboard SATA van dat J1900 bordje benutten. Maar daarboven kan het lastig worden ivm spinup current. WD Greens doen rond de 16W spinup. 60W netvoeding heb je al wel nodig met dat bordje + twee HDDs. 90W dus als je vier HDDs wilt. Al kan een netvoeding volgens mij ook tijdelijk meer stroom leveren.
Not again! The ECC discussion v8
Wel of geen ECC is al vaak besproken en men kent mijn mening hierin. Moet ik dat bij iedereen die ECC wilt nu gaan opleggen aan ze? Ze kunnen het opzoeken in dit topic en het ZFS topic en desgevraagd wil ik het best herhalen.
ECC is eigenlijk onmisbaar voor je RAM en de enige reden dat het niet standaard overal wordt ingezet zijn politiek-economische redenen, geen technische of kostentechnische redenen. Maar dat is de situatie waar we mee zitten. ECC moet je voor betalen.
Dat betekent ook dat je goed moet afwegen of je ook zonder kunt. Als de data sowieso niet belangrijk is, kan die afweging makkelijk worden gemaakt. Maar het ligt natuurlijk ook aan het soort risico wat je precies loopt. Daar heb ik zelf ervaring in en tevens heb ik wat dingen erover opgezocht. Ik claim niet dat ik alle factoren ken die hiervoor van toepassing zijn; dan had ik niet op GoT gezeten maar ergens in de Bahama's of Dubai. Maar mijn impressie is het volgende:
Zonder ECC kunnen bitfouten ongedetecteerd en ongecorrigeerd corruptie veroorzaken
Met ECC kunnen bitfouten extreem zelden ongedetecteerd en zelden ongecorrigeerd corruptie veroozaken.
Ook met ECC ben je er dus nog niet. Het blijft een zwakheid dat je applicatie niet kan rekenen op een 100% stabiel integere rekeneenheid. Maar, daar zijn we natuurlijk wel heel erg dichtbij.
De volgende vraag is, wat betekent het voor je applicaties en kernel die geheugen gebruiken als er bitfouten veroorzaakt worden in het geheugen. Vrijwel alle applicaties hebben geen enkele bescherming tegen corruptie in RAM. En kunnen dus crashen (goed nieuws) of vreemd gedrag gaan vertonen (slecht nieuws). In het slechtste geval bijvoorbeeld kan het een of andere database corrumperen in zo'n manier dat iets niet meer werkt na het herstarten. Dat soort dingen zijn gewoon erg vervelend.
Wanneer we onze focus verleggen op ZFS, dan vind ik mijn eigen ervaring hierin wel bruikbaar als basis voor een brede discussie. Want mijn ervaring is dus dat met RAM corruptie (ik had een defect RAM latje in mijn test server geduwd) het niet altijd tot permanente corruptie hoeft te leiden. Mijn latje was gewoon gaar; met MemTest zie je dan vele duizenden fouten als je hem een minuut laat draaien. Dan zijn we het er over eens dat dat veel bitfouten zijn, toch? Alleen is het mogelijk wel zo dat de bitfouten zich maar op bepaalde plekken voordoen, ipv willekeurig verdeeld zodat alle RAM plekken uitgetest worden.
Vervolgens heb ik op een bestaande ZFS pool een scrub gestart, met defect RAM geheugen. Er kwamen allerlei checksum errors voorbij; data op de disks zou niet conform de checksum zijn en is dus gecorrigeerd. In feite is juist die plek gecorrumpeerd, omdat door de RAM corruptie er verkeerde data wordt vergeleken.
Bij het herstarten met goed geheugen, heb ik vervolgens weer opnieuw een scrub gedraaid. Daarbij werd opnieuw corruptie gevonden; zeer waarschijnlijk veroorzaakt door de vorige scrub met defect RAM. Maar alle schade werd hersteld en alle bestanden waren intact. Van sommige grote bestanden heb ik de integriteit nog eens gechecked met een diff; dat leek verder allemaal goed.
De conclusie is dus waarschijnlijk dat ZFS wel kwetsbaar is voor RAM corruptie, maar zeker wel tegen een stootje kan op dat vlak. Zolang je pool redundant is, zul je bij corruptie van een data segment op één disk nog niet direct de data op de overige disks beïnvloeden.
Maar we mogen niet te vroeg juichen. Want als bij mutaties van bestanden en het vaststellen van de nieuwe checksum, er een verkeerde checksum wordt gegenereerd, dan wordt de data op alle redundante bronnen die deze corruptie niet vertonen, afgekeurd. Dan is je file dus stuk.
En dan kom ik terug op de afweging wel of geen ECC: hoe erg vind je het als individuele bestanden defect kunnen raken? Ik zelf vind het allang fijn dat ik weet welke bestanden het om gaat. Dan weet ik ook dat de rest dus in orde is. Die zekerheid is voor veel thuisgebruikers denk ik al voldoende. Het vermogen van ZFS om corruptie te
corrigeren is bekend en wordt veelal geroemd, maar het vermogen om corruptie te
detecteren wordt slechts zelden genoemd. Toch vind ik dat eigenlijk nog de krachtigste feature.