ECC geheugen voor zelfbouw ZFS NAS?

[Anoniem: 532949]

Hallo tweakers,

Ik zit al een tijdje te denken om een NAS te bouwen op basis van FreeNas of Nas4free , voor Backup van bestanden van meerde pc's. En om muziek op elk apparaat beschikbaar te hebben in huis. Verder zou ik graag ook een kleine FTP server willen draaien op de NAS.

Nu zit ik met een probleem, ZFS en ECC ram. Ik heb bijna overal gelezen dat je het beste ECC ram gebruikt om te voorkopen dat je date beschadigt als gevolg van "omgevallen" bit's. Dus toen dacht ik , " oke ik maak een NAS met ECC ram" . Maar dit is makkelijker gezegd dat gedaan, zeker met een budget van 500 euro inclusie 3 hdd's.

Er is op internet erg veel onduidelijkheid wel Intel chips ECC support hebben, en al vind je een goede chip, dan moet je nog een goed moederbord vinden.

Bij AMD schijnen de meeste FX cpu's ECC te ondersteunen, en de meeste AM3+ Asus mobo's ook. Maar ook hier is onduidelijkheid over !

Mijn vragen zij als volgt :
-Is het heel erg om geen ECC ram te gebruiken
- is er een OS waarmee je een NAS kan opzetten die geen ZFS naar bijv XFS gebruitkt , en zou je dan wel ECC kunnen gebruiken ?
- En heeft iemand ervaring met ecc support bij de AMD FX serie.


bronnen:
problemen ECC support Intel :
https://communities.intel.com/thread/60807
http://hardforum.com/showthread.php?t=1693051

bij amd
http://hardforum.com/showthread.php?t=1698299

[Anoniem: 15758]

Als je kunt leven met een situatie dat je achteraf te horen krijgt 'bestanden X en Y zijn corrupt' - dan kun je leven zonder ECC.

Bedenk echter dat alleen ECC op de server onvoldoende is. Je dient ECC ook uit te voeren op alle computers op het lokale netwerk die schrijfacties uitvoeren naar de NAS. Dus kortom, ook je desktop dient over ECC te beschikken. Sterker nog, de noodzaak voor ECC op de desktop is - voor thuisgebruikers - véél belangrijker dan ECC op de server. De server kan namelijk een groot deel van de corruptie ontstaan door RAM bitflips, achteraf corrigeren. Bovendien kan het - achteraf - ook alle corruptie detecteren. Maar je desktop heeft die luxe niet. Die heeft 0% correctiemogelijkheid en 0% detectiemogelijkheid. Als je desktop corrupte data aanlevert aan de ZFS NAS, hebben alle beveiligingen en ECC geheugen op de server natuurlijk ook geen zin.

ECC is echter absoluut noodzakelijk indien je End-to-End data protection nodig hebt; oftewel dat je applicaties gegarandeerd corruptievrije data aangeleverd krijgen. Een bank bijvoorbeeld, wil niet dat door een RAM bitflip opeens 10 miljard ipv 10 miljoen wordt bijgeschreven bij de rekening van een klant. Kortom, heb je zakelijke belangen dan is ECC vrijwel een must-have.

Bedenk ook dat de discussie rondom ECC fel wordt gevoerd. Er zijn veel verschillende meningen en opvattingen. Bedenk daarbij dat een groot deel van die opvattingen niet uitgaan van een thuissituatie en de belangen van een gemiddelde thuisgebruiker die een ZFS NAS wilt. Je zult voor jezelf moeten afwegen in hoeverre je het risico groot genoeg acht om je budget flink te verhogen zodat je gebruik kunt maken van ECC.

[Anoniem: 532949]

Bedankt voor je opheldering, heeft zeker wat meer inzicht gegeven.

De pc's die naar de NAS zullen uploaden zijn hier lichtere apparaten, zoals een paar laptop's , een tablet en mijn pc, welke allemaal niet te voorzien zijn van ECC geheugen. Het gaat niet om zeer belangrijks systemen. Wat ik wil bereiken is dat de bestanden die op de pc's staan ook nog een keer op een nas worden opgeslagen, zodat ze makkelijker bereikbaar zijn, en zodat er een Backup van is.

Over de correctiemogelijkheden van een server, wat bedoel je daar precies mee ? Snap je uitleg wel, maar begrijp niet zo goed waarom een server meer mogelijkheid tot correctie- detectiemogelijkheden heeft ?

[dcm360]

ZFS kan (in RAID-Z) detecteren dat er een bit is omgevallen, en achterhalen wat de correcte waarde was. Dit is op voorwaarde dat de bitflip er pas is nadat de checksum is berekend, want anders schrijft ZFS alsnog corrupte data met bijbehorende 'verkeerde' checksum weg en is dan van mening dat die data correct is.

Mijn inschatting zou zijn dat de kans ruim groter is dat de data corrupt raakt voordat ZFS de checksum berekent, dan de kans daarna. Maar misschien heeft CiPHER daar een ander inzicht in dan ik.

[BartNL]

wanneer je een beperkt budget hebt kun je voor genoemde taken zonder ECC. Kansberekening op fouten is naar mijn inschatting voor een thuis NAS meer academisch dan praktisch.
In feite heb je bij elke PC kans dat data fout wordt weggeschreven dan wel corrupt raakt. In de praktijk merk je daar weinig van. Een NAS voor backup is prima start om belangrijke data te beschermen.
Stel dat je NAS wel 100% data integriteit kan garanderen hoe zeker ben je dan dat het bron bestand waarvan je de backup maakt niet al corrupt is. Wanneer je je daar geen zorgen om maakt zou ik met een beperkt budget ook gewoon een NAS zonder ECC bouwen.

[HollowGamer]

De meerwaarde van ECC is alleen van toepassing bij Enterprises in mijn ogen. Reken daarbij je budget bij en je komt dan al snel tot de conclusie dat ECC weinig zin heeft.

Daarbij hebben ZFS en btrfs herstel mogelijkheden die 'vroeger' nog niet (zo makkelijk) waren om corruptie van je data tegen te gaan. Ik zie zelfs bedrijven om die reden geen gebruik maken van ECC (plus kosten en effectiviteit).

Kijk gewoon voor een extra Externe HDD waar je dagelijks een backup van je NAS op kan maken.

[Anoniem: 15758]

Anoniem: 532949 schreef op zaterdag 20 juni 2015 @ 16:26:
De pc's die naar de NAS zullen uploaden zijn hier lichtere apparaten, zoals een paar laptop's , een tablet en mijn pc, welke allemaal niet te voorzien zijn van ECC geheugen. Het gaat niet om zeer belangrijks systemen. Wat ik wil bereiken is dat de bestanden die op de pc's staan ook nog een keer op een nas worden opgeslagen, zodat ze makkelijker bereikbaar zijn, en zodat er een Backup van is.

Ik vind dat je zelf een beslissing moet nemen. Maar als ik dit zo lees, denk ik dat je in de categorie valt van mensen die prima zonder ECC kunnen leven. Dat je ZFS gebruikt, is namelijk je redding! Want: zou je een paar bitflips krijgen dan is het ergste dat praktisch kan gebeuren dat je een paar bestanden mist. En die worden dan ook keurig weergegeven in de lijst.

Maar, dan heb ik het over permanente corruptie. Er is nog een ander soort corruptie: tijdelijke corruptie. Daarmee bedoel ik: corruptie die na verloop van tijd weer wordt hersteld. Dit is typisch voor corruptie veroorzaakt door RAM bitflips. Eerst raakt de data corrupt - dus één blok in een RAID-Z1/2/3 - en wordt foutief naar de disk geschreven. De volgende keer wordt de corruptie ontdekt en evengoed weer hersteld en zie je een checksum error in de zpool status output.

Permanente corruptie betekent dat ook met goed RAM je niet meer foutloos je data kunt lezen. ZFS staat niet toe(*) dat foutieve data wordt aangeleverd. Alle aanvragen voor dit bestand door applicaties zullen worden afgewezen middels een I/O error. Dus je zult het bestand moeten verwijderen. Welke bestanden fout zijn kun je zien in de zpool status -v output.

De tijdelijke corruptie heeft als grote nadeel dat je applicatie - degene die bij leesacties om data vraagt - ook daadwerkelijk corrupte data in handen krijgt. De End-to-End Data Security Protection van ZFS wat juist dit moet voorkomen, wordt volkomen gepasseerd bij een RAM bitflip. Dus vanuit enterprise opzicht is ECC een absolute noodzaak. Alles wat niet ECC heeft, is onveilig. Nogmaals, vanuit hun perspectief. Volkomen terecht ook gezien hun belangen, dus op een aantal punten sterk afwijken van dat van thuisgebruikers.

Een thuisgebruiker is denk ik vooral geïnteresseerd in de permanente corruptie. De gebruiker wilt de bestanden niet kwijt. Als het betekent dat hij een keer moet rebooten of een RAM reepje vervangen of wat memtest draaien, prima. Als de data maar niet permanent naar de kl*te is, dát is wat belangrijk is voor een thuisgebruiker. Bij ZFS zit de datarecovery al in ZFS zelf. Dus als het niet meer te recoveren is volgens de ingebouwde beveiligingen, keurt ZFS het bestand af. Dat is dan jammer. Maar vergeet ook hier niet een héél groot en vooral zéér onderbelicht voordeel: ZFS zal uiteindelijk altijd weten of je bestand corrupt is of niet. Nooit meer onzekerheid hierover.

Natuurlijk zijn er altijd weer uitzonderingen. Dus hier alle die ik kan bedenken op een rij:

• Als ZFS de data al corrupt in handen krijgt, dan zijn alle beschermingsmechanismen voor niets. Dan ben je screwed.
• Een bitflip hoeft niet enkel ZFS te treffen. Het kan ook andere delen van je OS of applicaties treffen, zoals Samba die je bestanden doorgeeft via het netwerk. Of een netwerk TOE software driver die in RAM zijn werk doet. Kortom, de rest is ook kwetsbaar en heeft enorm veel potentie om schade aan te richten. Bedenk echter wel dat kernel en applicaties op een server prima 100MB kunnen zijn terwijl er vele tientallen gigabytes aan RAM naar ZFS gaan. In zo'n geval is de kans dat een RAM bitflip ZFS betreft natuurlijk heel groot. Echter, op het internet wordt soms beweerd dat ZFS meer kans zou hebben om getroffen te worden dan andere filesystems zoals NTFS, omdat die minder geheugen zouden gebruiken. Maar dit onjuist. Legacy filesystems met caching VFS-laag (sinds Windows NT4) doen aan filecache en dat vult in principe alle RAM, terwijl ZFS zichzelf beperkt tot een gedeelte van de RAM, ook als er nog vrij geheugen is. Dus ZFS gebruikt in principe minder RAM en heeft dus ook iets minder exposure.
• ZFS slaat naast data ook metadata op. Die metadata is cruciaal, want die is nodig om de data te kunnen lezen. Dat is de 'structuur' van het filesystem. ZFS heeft standaard al een extra veiligheidsmechanisme voor metadata - het slaat standaard minimaal 2 kopieën op van de metadata. Dus ook als je maar een enkele disk gebruikt in een ZFS pool. Zo kan een bad sector of corrupte block nooit het filesystem zelf onderuit halen. Alleen data kan aan geknaagd worden. De kans dat je twee corrupte/bad blocks op precies de verkeerde - willekeurige - plek hebt, is zeer klein. Als metadata corrupt raakt, kun
• Naast de failuremodes hierboven besproken is nog een belangrijke failuremode dat bij het aanmaken van een checksum de checksum zelf foutief wordt berekend. In dat geval zullen alle blocks van een RAID-Z vdev worden afgekeurd. Immers: ze voldoen niet aan de checksum. Dan krijg je dus gelijk de melding dat een bestand corrupt is. Technisch valt deze failuremode echter niet onder permanente corruptie, omdat de data alsnog te recoveren is door ZFS te instrueren om corrupte files niet te weigeren met een I/O error maar foutief aan te leveren. Dit is het punt waar ik hierboven een sterretje(*) heb gegeven.
• Naast een enkele RAM bitflip per write cycle, kunnen er ook meerdere bitflips plaatsvinden. Zo kunnen er drie bitflips plaatsvinden op een RAID-Z2 vdev en dat breekt de bescherming waardoor ook dat bestand corrupt zou raken.
• Het absolute doemscenario is dat je hele pool corrupt raakt. Dit kan gebeuren indien de essentiële metadata corrupt raakt, of niet meer consistent is met elkaar. De enige manier die ik ken om dit voor elkaar te krijgen is door ZFS op een hardware RAID controller met onveilige write-back te gebruiken. Dan verandert namelijk de volgorde van writes ook over de 'FLUSH CACHE'-boundaries die ZFS stuurt naar de hardeschijven. Hierdoor kan bij een crash de essentiële metadata zichzelf tegenspreken. Kortom, als ZFS op cruciale plekken op de disks niet de data vindt die het wilt vinden, dan ben je de sjaak. Maar, omdat deze metadata tot 16 kopieën heeft over de disk, moeten er wel gekke dingen gebeuren. Het valt echter niet uit te sluiten dat een RAM bitflip ook hiervoor kan zorgen. Ik wil daarbij wel opmerken dat er nog nooit een melding is gemaakt van een dergelijke situatie in de historie, en ik volg toch aardig te mailinglists en andere bronnen. Bovendien kon ik met mijn eigen tests (zie hieronder) dit ook niet reproduceren. Enkel corrigeerbare fouten. Dit risico kan dus worden bestempeld als een potentiëel risico - dat enkel theoretisch bestaat en dankzij de grote exposure in 'het wild' beperkt blijft tot een statistisch zeer klein risico.

Over de correctiemogelijkheden van een server, wat bedoel je daar precies mee ? Snap je uitleg wel, maar begrijp niet zo goed waarom een server meer mogelijkheid tot correctie- detectiemogelijkheden heeft ?

Zie het bovenstaande. Andere filesystems van de 2e generatie - NTFS (Windows) - Ext4 (Linux) - HFS (Apple) hebben helemaal geen beveiliging whatsoever. Je zult mogelijk nooit weten dat je data corrupt is, en vrolijk naar je backups stroomt. Dat mag toch anno 2015 niet meer. Kom nou toch...

dcm360 schreef op zaterdag 20 juni 2015 @ 19:06:
Mijn inschatting zou zijn dat de kans ruim groter is dat de data corrupt raakt voordat ZFS de checksum berekent, dan de kans daarna. Maar misschien heeft CiPHER daar een ander inzicht in dan ik.

Ik heb dit niet kunnen reproduceren met mijn corruptietest, waarbij ik een defect RAM reepje gebruikte in mijn oude server - Athlon 64 denk ik. Voor de test heb ik het reepje met MemTest86 getest en daarbij werden al binnen enkele seconden tienduizenden fouten getoond. Dus niet een béétje defect reepje, nee wel helemaal ruk zeg maar.

Op de server voerde ik vervolgens een scrub uit en liet ik wat scripts draaien op de pool. Daarbij zag ik checksum fouten bij de eerste keer, toen ZFS valide data van de disks kreeg en deze als corrupt aanmerkte door RAM bitflips van deze data. Bij een tweede ronde wordt de reeds corrupte data evengoed weer gecorrigeerd door de RAID-Z2 bescherming, maar wordt evengoed weer nieuwe corruptie gegenereerd. Daarna afsluiten en met een gezond RAM reepje de pool laten scrubben. En een heleboel checksum fouten zoals eerst ook, maar geen permanent corrupte files. Van een aantal files bij een scriptje had ik ook de originele MD5, en die klopte ook gewoon.

Dat gezegd, het was maar zomaar een test omdat ik nieuwsgierig was. Een echt goede test waarbij ik veel dingen wil testen, is er nog niet. Het beste zou zijn als je met QEMU ofzoiets RAM kan corrumperen, en je dus bijvoorbeeld testjes kunt doen met een instelbaar percentage aan RAM bitflips. Of juist burst van flips. Of iets aan de random distributie veranderen zoals ze clusteren. Etcetera.

Maar ik heb er de tijd niet voor. Sorry, ik heb nu een druk leven. Tijden veranderen. Misschien ooit. Maar dan wil ik het ook gelijk goed doen, en er een speciale website voor maken, zodat de heilige ECC kruistochten een eind kunnen worden aangeroepen en mensen gewoon een nuchtere keuze kunnen maken of ze het de meerprijs waard vinden.

[HollowGamer]

@CiPHER: erg interessante info over ZFS.
Hoe zit dit met btrfs, biedt deze dezelfde beveiliging tegen datacorruptie?

[Q]

ECC RAM is belangrijk als je geeft om data integriteit en beschikbaarheid. Als dat niet zo super belangrijk is, dan kun je best zonder ECC geheugen of ZFS. Ieder file system is prima. ZFS beschermt tegen allerlei risico's waar andere file systems niet tegen beschermen, maar voor thuis is dat iets waar je per geval moet nadenken of dat wel zo spannend is.

In jouw context zou ik me afvragen of een zelfbouw NAS wel de beste oplossing/nodig is, maar als dat economisch beter uitkomt, bouw waar jij comfortabel mee bent.

Ik heb zelf 7 jaar een 18TB zelf bouw nas gehad en het is nooit mis gegaan. Met mijn nieuwe 71 TB NAs neem ik geen risico: ik kan geen backups maken van zoveel data: dus als het ding plat gaat dan ben ik alles kwijt. Dat blijft een risico, maar ECC geheugen is in deze context wel zo verstandig. Maar dat is geen vergelijkbare situatie.

Or let Matthew Ahrens, the co-founder of the ZFS project phrase it:

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than
any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

Let op de volgorde.

[ Voor 44% gewijzigd door Q op 21-06-2015 10:08 ]

[Anoniem: 532949]

CiPHER, bedankt voor de zeer nuttig uitleg ! ik ga denk voor een NAS zonder ecc, al blijf ik het riskant vinden. Maar het is niet zo dat de data zeer belangrijk is. Ik moet zeggen dat ik onder de indruk ben van je kennis over ZFS, en ik ben nu ook overtuigt dat dat een goed fille systeem is. Je voorbeeld van de test met het defecte ram was ook een erg goed toevoeging.


Q, wat voor Fille syteem gebruikte je met je 8tb NAS ?

Nog even iets anders, weet iemand hoe het zit met de FX cpu's van AMD en ECC support , ik hoor verschillende verhalen.

[ Voor 23% gewijzigd door Anoniem: 532949 op 21-06-2015 13:10 ]

[Q]

Mijn oude file server gebruikte MDADM + XFS.

Ik ben ook onder de indruk van de lappen tekst die CiPHER in korte tijd weet te produceren.
Over de inhoud en de essentie ben ik minder onder de indruk maar ik heb geen zin om die discussie te herhalen.

Ik heb hier mijn standpunt verwoord.

http://louwrentius.com/please-use-zfs-with-ecc-memory.html

De kern van de discussie tussen mij en een hoop anderen is altijd geweest: Je kiest ZFS voor de data integriteit. Data integriteit is niet alleen ZFS, dan heb je ook ECC geheugen nodig.

Ben je dan toch beter af met ZFS thuis ook al kies je voor non-ECC geheugen? CiPHER meent van wel. Ik zeg: met de argumenten waarmee je de noodzaak van ECC voor thuis bagataliseert kun je ZFS ook opzij schuiven (groot verschil is dat ZFS gratis is en ECC geld kost, maar dat is niet de discussie). Dat maakt het leven voor thuis een stuk makkelijker want dat geeft je meer keuze vrijheid, die beter past bij jouw kennis/ervaring/budget. Misschien is een QNAP of Synology wel een betere keuze voor je.

Het is sowieso raadzaam om kritische data, zoals je prive foto's in de cloud te stoppen (crashplan backblaze, etc).

[ Voor 7% gewijzigd door Q op 21-06-2015 13:46 ]

[Anoniem: 15758]

Je kiest ZFS voor de data integriteit.

Heel veel mensen kiezen voor ZFS omdat ze permanente corruptie willen tegengaan. Kortom, ze willen dat hun data de tijd overleeft. Dit is niet hetzelfde als data-integriteit. Een bank kan niet toestaan dat data tijdelijk corrupt raakt. Thuisgebruikers kunnen dat veelal prima verdragen.

Kortom, ik blijf bij het standpunt dat fanatieke voorstanders van ECC zich vereenzelvigen met belangen die vooral grote bedrijven - enterprise-gebruikers - hebben en die gaan veel minder op voor normale thuisgebruikers. Die willen voor weinig geld een hoge mate bescherming voor hun bestanden zodat hun data de tijd kan overleven.

Het afdoen van een non-ECC ZFS server als onzinnig ("dan kun je beter helemaal geen ZFS gebruiken") is grote onzin. Daar is geen enkel zinnig argument voor en is denk ik meer een zure reactie van mensen die inzien dat veel ZFS gebruikers toch voor non-ECC kiezen. Ook op het FreeNAS forum tel je niet mee als je server niet over ECC beschikt. Dergelijke zeeloten gaan totaal voorbij aan de individuele belangen die sterk afwijken van hun eigen persoonlijke belangen en hun persoonlijke afweging begint meer op een religie te lijken dan een nuchtere en objectieve afweging of de meerwaarde van ECC opweegt tegen de extra kosten.

Uiteraard deel ik het advies van Q om extra belangrijke data - zoals persoonlijke foto's en documenten - extra te backuppen. Dat kan vaak ook prima omdat juist deze data veelal veel kleiner is in omvang dan de bulk data. Maar zou je geen ZFS gebruiken dan zou je ook nooit weten of corruptie naar je backups vloeit, dus errordetectie is eigenlijk een noodzaak als het om backups gaat - veel meer nog dan ECC. Immers, als ZFS laat weten dat bestand X corrupt is, kun jij deze van een oudere backup terughalen. Zonder deze detectie ga je vrolijk door met backuppen en veelal worden oudere (incremental) backups daarbij overschreven. Hierdoor kunnen dus al je duizend backups corrupt raken en heb je dus weinig aan de schijnzekerheid die een dergelijke constructie biedt.

Zou je in plaats van ZFS naar QNAP of Synology gaan, dan offer je extreem veel voordelen op in termen van databescherming. Je gaat dan terug naar een vorig tijdperk met 2e generatie filesystems die geen enkele bescherming bieden. Het enige beschermingsmechanismen van dergelijke filesystems, is die tegen het verliezen van de gegevens in de DRAM-chip voor buffered writes. Daar kan een 1e generatie filesystem (FAT, Ext2, UFS1) niet tegen maar een 2e generatie filesystem (NTFS, Ext3/4, UFS2+SU) wel. Maar dan houdt het ook op; legacy filesystems bieden geen bescherming. De stap naar ZFS is een extreem grote stap, en voor thuisgebruikers voegt ECC daar slechts een klein beetje extra zekerheid bij. En zoals Q al zegt, ZFS is gratis; ECC kan voor een flinke verhoging van het budget zorgen.

[BartNL]

voordeel van bijvoorbeeld QNAP en Synology is dat het gebruikersvriendelijk is, goed ondersteund wordt en jaren doorontwikkeld is. Daardoor zijn ze zeker te overwegen en misschien wel superieur voor de technisch minder geïnteresseerde gebruiker.
Grootste probleem bij databescherming blijft menselijk falen en die kans is met de huidige ZFS oplossingen naar mijn idee groter.

[ Voor 3% gewijzigd door BartNL op 21-06-2015 14:22 ]

[Anoniem: 15758]

Maar de gebruiksvriendelijkheid staat hier niet ter discussie. Dat is tevens persoonlijk en niet louter objectief vast te stellen. Sommige mensen vinden FreeNAS fijn, sommigen zweren bij Synology, terwijl anderen enkel op de command line werken. Dat zijn grote verschillen.

Ook andere oorzaken van dataverlies zijn het zeker waard om te doorgronden, zoals user error. ZFS biedt ook hier gedeeltelijk bescherming dankzij de snapshots, waarbij je terug in de tijd wilt en ZFS dus een overlappende bescherming biedt met backups. Want het terug in de tijd gaan is normaliter een bescherming die backups bieden. Maar technieken als ZFS snapshots, Windows Previous Version of Apple TimeMachine eten steeds meer stukjes van de taart die voorheen in het exclusieve domein vielen van backups.

Maar misschien moeten we ons tot het onderwerp beperken - wel of geen ECC voor je ZFS Thuis NAS - en dit topic niet te breed maken door alle data security centraal te stellen, want dan krijgen we een veel grotere discussie en ik betwijfel of dat wenselijk is.

[Q]

Anoniem: 15758 schreef op zondag 21 juni 2015 @ 14:16:
[...]
fanatieke voorstanders
een zure reactie
tel je niet mee
zeeloten
meer op een religie te lijken dan een nuchtere en objectieve afweging

Tja, de gekleurde bewoording van CiPHER zoals we ze gewend zijn.

CiPHER doet alsof de risico's waar ECC geheugen tegen beschermt minimaal zijn en dat je enorm gevaar loopt als je geen ZFS gebruikt.

Dat noem ik onnodige bangmakerij.

Het feit is dat iedereen zijn foto's meestal op zijn/haar eigen PC bewaart. Apparaten die geen ECC bevatten en geen ZFS draaien. Zie ik hier nu 20 mensen in paniek raken? Vergaat de wereld?

Denk het niet

Kies een oplossing waar je zelf het meest comfortabel bij bent. Als dat een QNAP/Synology is, ok. Zelfbouw met ZFS zonder ECC geheugen, prima. Ieder zijn/haar keuze.

[ Voor 9% gewijzigd door Q op 21-06-2015 15:36 ]

[FireWood]

Discussie is eigenlijk heel makkelijk:
ZFS beschermt tegen rotte bits op je harde schijf.
ECC beschermt tegen rotte bits op je werkgeheugen.

Een paar jaar geleden was het zeker duidelijk dat rotte bits in werkgeheugen vaker voorkwamen dan op harde schijven: Eerst ECC daarna ZFS. Tegenwoordig worden de harde schijven helaas onbetrouwbaarder betreffende rotte bits en zal het niet veel meer schelen (laatste even zonder onderbouwing)

Wil je zekerheid moet je ze alle twee toepassen.

[Anoniem: 15758]

FireWood schreef op zondag 21 juni 2015 @ 15:52:
Discussie is eigenlijk heel makkelijk:
ZFS beschermt tegen rotte bits op je harde schijf.
ECC beschermt tegen rotte bits op je werkgeheugen.

Dat is mooi gezegd, maar zou ik als onvolledig en onjuist typeren.

ZFS wordt vooral geprezen om zijn bescherming tegen corruptie op de disk. Maar dan hebben mensen het altijd over de errorcorrectie mechanismen. Een veel minder geprezen maar mijns inziens véél belangrijker voordeel van ZFS is de errordetectie. Simpelweg wéten of data corrupt of niet is, is de eerste stap naar veiligheid.

Met ZFS heb je bijna alles al afgedekt, maar een blijft nog een gat open door non-ECC RAM wat voor corrupte files kan zorgen én voor tijdelijke corruptie kan zorgen (je applicaties krijgen foute data). Dat zijn twee risico's die voor thuisgebruikers prima te managen is, vooral dankzij de errordetectie van ZFS.

Dus dat ZFS enkel tegen disk corruptie zou beschermen, verwerp ik. Neem het voorbeeld van defect RAM geheugen. Veel mensen komen erachter dat hun nieuw gebouwde ZFS NAS een defect RAM latje heeft, doordat ZFS checksum errors op meerdere disks geeft - veelal in een willekeurig patroon. Dan weet je dat defect RAM vrijwel zeker de oorzaak is en kun je na MemTest86 vrolijk weer verder. Kortom, het is de errordetectie die de echte wonderen verricht - correctie is eigenlijk van secundair belang.

[begintmeta]

Errordetectie en -correctie in data is in mijn ogen vooral de taak van de sofware die die data be-/verwerkt. Voor bestandssystemen betekent dat dan dus dat die mechanismen er voor de metadata(de data van het bestandssysteem) moeten zijn. Zodanig kan ik me aansluiten bij de lijn die XFS heeft genomen.

Aan de andere kant doet veel software niet veel aan errordetectie of -correctie, terwijl dat voor die software wel wenselijk zou zijn. Dan zijn toevoegingen die dit wat opvangen zoals in zfs, btrfs of hammer (of ook hardware) doen wel een goed idee natuurlijk.

[ Voor 3% gewijzigd door begintmeta op 21-06-2015 17:24 ]

[Q]

Anoniem: 15758 schreef op zondag 21 juni 2015 @ 16:01:
[...]
Neem het voorbeeld van defect RAM geheugen. Veel mensen komen erachter dat hun nieuw gebouwde ZFS NAS een defect RAM latje heeft, doordat ZFS checksum errors op meerdere disks geeft - veelal in een willekeurig patroon. Dan weet je dat defect RAM vrijwel zeker de oorzaak is en kun je na MemTest86 vrolijk weer verder. Kortom, het is de errordetectie die de echte wonderen verricht - correctie is eigenlijk van secundair belang.

Kijk nu toch, ZFS is zelfs een vervanger van MemTest86!!!
Dit is te zot voor woorden.

[FireWood]

Anoniem: 15758 schreef op zondag 21 juni 2015 @ 16:01:
[...]

Dat is mooi gezegd, maar zou ik als onvolledig en onjuist typeren.

ZFS wordt vooral geprezen om zijn bescherming tegen corruptie op de disk. Maar dan hebben mensen het altijd over de errorcorrectie mechanismen. Een veel minder geprezen maar mijns inziens véél belangrijker voordeel van ZFS is de errordetectie. Simpelweg wéten of data corrupt of niet is, is de eerste stap naar veiligheid.

Met ZFS heb je bijna alles al afgedekt, maar een blijft nog een gat open door non-ECC RAM wat voor corrupte files kan zorgen én voor tijdelijke corruptie kan zorgen (je applicaties krijgen foute data). Dat zijn twee risico's die voor thuisgebruikers prima te managen is, vooral dankzij de errordetectie van ZFS.

Dus dat ZFS enkel tegen disk corruptie zou beschermen, verwerp ik. Neem het voorbeeld van defect RAM geheugen. Veel mensen komen erachter dat hun nieuw gebouwde ZFS NAS een defect RAM latje heeft, doordat ZFS checksum errors op meerdere disks geeft - veelal in een willekeurig patroon. Dan weet je dat defect RAM vrijwel zeker de oorzaak is en kun je na MemTest86 vrolijk weer verder. Kortom, het is de errordetectie die de echte wonderen verricht - correctie is eigenlijk van secundair belang.

Heb bijna het idee zoals jij het opschrijft dat ZFS alles kan
Als een bestand moet worden weggeschreven wat binnengekomen is via het netwerk en in het RAM komt waar één bitrot in zit, zal ZFS die echt niet vinden. Simpelweg, omdat de checksum rekening houd met die fout.
Verder is het leuke dat ZFS er vanuit gaat dat alles wat in het geheugen komt goed is. Op zich logisch, aangezien ZFS is ontworpen voor servers, waar altijd ECC wordt gebruikt. Maar als het fout zit heb je kans dat de hele pool onbruikbaar wordt. Recovery is onmogelijk....
Onderzoek betreffende dit

[Anoniem: 15758]

begintmeta schreef op zondag 21 juni 2015 @ 16:43:
Errordetectie en -correctie in data is in mijn ogen vooral de taak van de sofware die die data be-/verwerkt.

Dus de applicatie moet maar mechanismen inbouwen dat de data veilig kan worden opgeslagen? Dan zou elke applicatie zelf iets moeten knutselen? Daar heb je toch juist een filesystem voor? Het hele idee van het opdelen van software is dat je - volgens de UNIX filosofie - één component hebt wat één bepaalde taak heel goed uitvoert, en kan worden gecombineerd met andere componenten in vele vaak vooraf niet denkbare combinaties. Het kenmerk hierbij is dat het een voordeel is dat de componenten klein en relatief simpel zijn. Zo kunnen complexe systemen uiteindelijk toch betrouwbaar functioneren.

Het filesystem heeft natuurlijk de beste positie om een dergelijke bescherming uit te voeren. Dus de bescherming van het filesystem naar de applicatie afwimpelen is natuurlijk niet de toekomst. De toekomst is dat alle platforms (Windows, Linux, UNIX) naar 3e generatie filesystems toe gaan. Niet terug in de tijd naar 2e generatie filesystems zoals XFS.

FireWood schreef op zondag 21 juni 2015 @ 17:26:
Als een bestand moet worden weggeschreven wat binnengekomen is via het netwerk en in het RAM komt waar één bitrot in zit, zal ZFS die echt niet vinden. Simpelweg, omdat de checksum rekening houd met die fout.

Dat punt heb ik reeds genoemd in mijn lijst van uitzonderingen. Punt nummer 1: de data is al corrupt voordat het in de handen van ZFS komt. Daarom ook ECC op al je desktops als je het goed wilt doen.

Verder is het leuke dat ZFS er vanuit gaat dat alles wat in het geheugen komt goed is. Op zich logisch, aangezien ZFS is ontworpen voor servers, waar altijd ECC wordt gebruikt. Maar als het fout zit heb je kans dat de hele pool onbruikbaar wordt. Recovery is onmogelijk....
Onderzoek betreffende dit

Leuke studie, maar net als de BackBlaze-studie en de Google-studie kunnen hieruit verkeerde conclusies worden getrokken. Dit omdat de studie net als de twee andere studies, helemaal uitgaat van het perspectief van de Enterprise-gebruiker.

De paper gaat in op tijdelijke corruptie - niet op permanente corruptie. Wat de paper bewijst is dat ZFS' End-to-End Data Security Protection faalt zodra de RAM corruptie vertoont. ZFS heeft geen mechanismen om de applicatie bij RAM bitflips tóch goede data aan te leveren, of helemaal niet, zoals het wel kan met on-disk corruptie.

Maar dat is voor de thuisgebruiker niet zo relevant. Wat relevant is of de data definitief weg is of niet. Als de data weer kan worden hersteld na een volgende scrub of handelingen zoals MemTest86 gevolgd door het vervangen van een RAM reepje, dan is er niet zoveel aan de hand. Voor de thuisgebruiker - wel te verstaan. Want voor Enterprise-gebruikers is het een gruwel als applicaties corrupte data ontvangen. Daar zit hem het verschil.

De paper gaat dus totaal niet op het punt dat bij een volgende scrub de fouten altijd aan het licht komen. Of de checksum is zelf fout en de hele file wordt afgekeurd. Of de data is fout en wordt naar aanleiding van de correcte checksum hersteld. Voor de thuisgebruiker is vooral die zekerheid, dat hij of zij altijd zal weten wat wel en wat niet goed is, enorm veel waard. Veel meer waard dan de correctie mechanismen. Want: als een bestand echt belangrijk was, heb je die in je backup. De detectie zorgt ervoor dat je nooit voor vreemde verrassingen komt te staan als je na lange tijd je trouwfoto's weer eens opzoekt en merkt dat enkelen beschadigd zijn met artefacts, en dat hetzelfde probleem ook naar je backups is gevloeid. Dat soort zaken zul je als thuisgebruiker met ZFS enorm goed kunnen tackelen.

Kortom, de paper gaat in op tijdelijke corruptie, terwijl voor thuisgebruikers vooral de permanente corruptie relevant is.

[Q]

Op het moment dat je geheugen rot is, heeft iedere schrijfbewerking naar je ZFS file system de potentie om corruptie in het file systeem te veroorzaken.

ZFS moet het RAM geheugen gebruiken als kladpapier om haar eigen interne modificaties uit te voeren op het file systeem zelf als je er bewerkingen op doet. Als de uitkomst van een berekening in rot geheugen terecht komt zal ZFS dat niet door hebben. Niet alleen end-user data kan zo aangetast worden, maar het file system zelf ook. Dat kan desastreuze gevolgen hebben voor het hele file system. Worst-case kun je de pool niet meer mounten en is alles weg.

CiPHER, je wekt de indruk dat ZFS magischer wijze kan omgaan met rot geheugen, maar dat is wat mij betreft een onjuiste voorstelling van zaken. Je creëert zo een vals gevoel van veiligheid bij de mensen die op basis van dit soort verhalen op ZFS duiken.

Maar ongeacht de keuze voor een file system of wat de TS ook wil. Kijk eens naar dit doosje:

http://tweakers.net/produ...roliant-microserver-gen8/

[ Voor 25% gewijzigd door Q op 21-06-2015 18:21 ]

[FireWood]

Anoniem: 15758 schreef op zondag 21 juni 2015 @ 16:01:
[...]

Dat is mooi gezegd, maar zou ik als onvolledig en onjuist typeren.

Misschien onvolledig, maar wat verwacht je dan in één zinnetje. Onjuist is het zeker niet. Ze beveiligen waar ze voor gemaakt zijn en meer niet.

Anoniem: 15758 schreef op zondag 21 juni 2015 @ 17:48:
[...]

...

[...]

Leuke studie, maar net als de BackBlaze-studie en de Google-studie kunnen hieruit verkeerde conclusies worden getrokken. Dit omdat de studie net als de twee andere studies, helemaal uitgaat van het perspectief van de Enterprise-gebruiker.

De paper gaat in op tijdelijke corruptie - niet op permanente corruptie. Wat de paper bewijst is dat ZFS' End-to-End Data Security Protection faalt zodra de RAM corruptie vertoont. ZFS heeft geen mechanismen om de applicatie bij RAM bitflips tóch goede data aan te leveren, of helemaal niet, zoals het wel kan met on-disk corruptie.

Maar dat is voor de thuisgebruiker niet zo relevant. Wat relevant is of de data definitief weg is of niet. Als de data weer kan worden hersteld na een volgende scrub of handelingen zoals MemTest86 gevolgd door het vervangen van een RAM reepje, dan is er niet zoveel aan de hand. Voor de thuisgebruiker - wel te verstaan. Want voor Enterprise-gebruikers is het een gruwel als applicaties corrupte data ontvangen. Daar zit hem het verschil.

De paper gaat dus totaal niet op het punt dat bij een volgende scrub de fouten altijd aan het licht komen. Of de checksum is zelf fout en de hele file wordt afgekeurd. Of de data is fout en wordt naar aanleiding van de correcte checksum hersteld. Voor de thuisgebruiker is vooral die zekerheid, dat hij of zij altijd zal weten wat wel en wat niet goed is, enorm veel waard. Veel meer waard dan de correctie mechanismen. Want: als een bestand echt belangrijk was, heb je die in je backup. De detectie zorgt ervoor dat je nooit voor vreemde verrassingen komt te staan als je na lange tijd je trouwfoto's weer eens opzoekt en merkt dat enkelen beschadigd zijn met artefacts, en dat hetzelfde probleem ook naar je backups is gevloeid. Dat soort zaken zul je als thuisgebruiker met ZFS enorm goed kunnen tackelen.

Kortom, de paper gaat in op tijdelijke corruptie, terwijl voor thuisgebruikers vooral de permanente corruptie relevant is.

Dit klopt dus gewoon niet. Als een block in het RAM staat en daar beschadigd wordt, wordt dat blok met een nieuwe checksum weer teruggeschreven. ZFS kijkt niet naar de oude checksum die bij dat stukje data hoort. Aangezien alles mee wordt geupdate heb je ook geen recovery meer. Als het toevallig een stuk is van de metadata levert dat gewoon grote problemen op.

Observation 1: ZFS does not use the checksums in the page cache along with the blocks to detect memory corruptions. Checksums are the first guard for detecting data corruption in ZFS. However, when a block is already in the page cache, ZFS implicitly assumes that it is protected against corruptions. In the case of reads, the checksum is verified only when the block is being read from the disk. Following that, as long as the block stays in the page cache, it is never checked against the checksum, despite the checksum also being in the page cache (in the block pointer contained in its parental block). The
result is that ZFS returns bad data to the user on reads. For writes, the checksum is generated only when the block is being written to disk. Before that, the dirty block stays in the page cache with an outdated checksum in the block pointer pointing to it. If the block is corrupted in the page cache before it is flushed to disk, ZFS calculates a checksum for the bad block and stores the new checksum in the block pointer. Both the block and its parental block containing the block pointer are written to disk. On subsequent reads of the block, it passes the checksum verification and is returned to the user. Moreover, since the detection mechanisms already fail to detect memory corruptions, recovery mechanisms whether the operation completed (.). Large blanks mean that the osuch as ditto blocks and the mirrored zpool are not triggered to recover from the damage.
The results in Table 5 indicate that when a data block was corrupted, the application that issued a read() or
write() request was returned bad data (, as shown in the last row. When metadata blocks were corrupted, ZFS accessed the corrupted data structures and thus behaved wrongly, as shown by other cases in the result table.

Maar zoals ik het nu lees maakt het niet uit zolang je maar detecteert dat er een fout is. Als je hele systeem uitvalt en totaal onleesbaar wordt is het ook prima. Weet je tenminste dat er iets mis is.
Ik durf nu te beweren dat data-integriteit in thuis situaties belangrijker is dan bij bedrijven, aangezien bedrijven in het algemeen wel goede backup-systemen hebben. De eerste die thuis een goede backup heeft van zijn complete NAS moet ik nog tegen komen. (Er al vanuit gaande dat er backup is) Op zijn hoogst is alleen de belangrijke data gebackupd.

[SMSfreakie]

hier draait ze ook een zelfbouw NAS zonder ECC... bordje ondersteunt het wel. CPUtje ook...
de vorige NAS heeft 3 jaar feilloos gelopen ( ok ok geen garantie voor de toekomst natuurlijk )

reden van vervanging.. CPUtje kon het niet meer bij benen.. ( dualcore @ 1.65ghz -> octocore @ 2.4ghz)
zou er zo ECC stickjes in kunnen steken. alleen deze DDR3 modules lagen er nog...

en gezien er toch eigenlijk geen onmisbare data op staat..... en uh mn laptops / desktop / tablets gebruiken toch ook geen ECC... dus is het dan wel echt nuttig?

[Q]

ECC en ZFS nemen risico's weg die echt zijn. De risico's zijn klein maar op de schaal van bedrijven is de kans dat ze optreden groot en de impact is ook veel groter qua beschikbaarheid.

Bedrijven passen ECC toe in servers en bijbehorende storage is meestal gebaseerd op dure enterprise disks met grotere sectoren die parity informatie bevatten, een soort hardwarematige beperkte versie van wat ZFS doet.

Als een client plat gaat wordt 1 gebruiker getroffen. Gaat een server plat worden 100 gebruikers getroffen.

Nou is de grap, door thuis een NAS neer te zetten ga je dus in feite zelf thuis een server draaien. Met veel minder gebruikers natuurlijk. Maar de risico's gelden voor thuis net zo hard, maar de kans dat je thuis er door gegroffen wordt is klein. Niet nul, maar klein.

De kans wordt nul als je ECC en ZFS toepast. ECC kost geld, ZFS is gratis qua geld maar heeft andere kosten in termen van tijd en kennis.

ECC geheugen toepassen is fool-proof, als je een computer zelf kunt bouwen dan kun je ook ECC geheugen toepassen. Het enige nadeel is het geld.

ZFS implementeren is niet fool-proof, dat vereist wat meer handigheid met computers. FreeNAS of ZFSguru op een USB stickje installeren is niet zo moeilijk, maar de vraag is of je ook eventuele problemen aan kunt.

Niet iedereen is een BSD/Linux expert. User error kan in deze context al snel een groter risico worden voor de data dan de risico's waar ZFS tegen beschermd. Het is in die context veel belangrijker dat je een NAS neerzet die je ook zelf kunt beheren en repareren met de kennis die je hebt. Zeker als je problemen krijgt door rot geheugen.

In die context kun je mogelijk beter af zijn met Windows en een hardware RAID controller. Een kleine Windows NAS met ECC geheugen & harwdware RAID kan een formidabel stabiel platform zijn. Een hoop van de 20+ TB NAS bouwers hebben ook voor die aanpak gekozen.

Wat dat betreft zijn veel mensen - als het om veiligheid en beschikbaarheid gaat - vaak zelfs beter af met door fabrikanten geteste en gesupporte producten - in plaats van zelf bouw. Aan de ene kant 100 euro besparen om dan wel er een weekend of twee voor in te leveren om alles goed werkende te krijgen als het al niet later crashed. Als het je hobby is, ok natuurlijk, maar dat is weer een andere context.

Ik wil zeker niet de indruk wekken dat mensen om deze reden maar wegblijven van ECC of ZFS, maar dat ze de disciussie in de juiste context zien en dat kunnen vertalen naar hun eigen situatie en daarbij hoort de hele context.

[begintmeta]

Anoniem: 15758 schreef op zondag 21 juni 2015 @ 17:48:
... Het filesystem heeft natuurlijk de beste positie om een dergelijke bescherming uit te voeren. Dus de bescherming van het filesystem naar de applicatie afwimpelen is natuurlijk niet de toekomst. ...

Je schuift ook niet de bescherming van het filesystem af naar de applicatie in 'mijn geval', maar in 'jouw geval' de controle en bescherming van de applicatiegegevens naar het filesystem. De applicatie is in een betere positie om de fysieke en logische integriteit van die data te bewaken, omdat die als enige kan controleren wat naar het filesystem zou moeten worden geschreven, en wat vanuit het filesystem de applicatie weer binnen is gekomen/ wat in het applicatiegeheugen zit.

Het filesystem kan alleen controleren wat daar binnenkomt en uitgaat, maar de applicatie is toch het niveau waarop de data uiteindelijk wordt aangemaakt/bewerkt, opgeslagen en weer ingelezen, dus daar moet om het goed te doen toch nog een controle van de fysieke en logische integriteit zijn, die dan de filesystemcheck min of meer overbodig maakt. In principe, in praktijk is die check er vaak niet of onvoldoende natuurlijk, en dan is het heel fijn als het filesystem (en bijvoorbeeld ecc-geheugen) een (groot) deel van die bewaking van in iedergeval de fysieke integriteit op zich neemt.

[ Voor 11% gewijzigd door begintmeta op 23-06-2015 18:33 ]

[Anoniem: 15758]

FireWood schreef op zondag 21 juni 2015 @ 19:42:
Dit klopt dus gewoon niet. Als een block in het RAM staat en daar beschadigd wordt, wordt dat blok met een nieuwe checksum weer teruggeschreven.

Maar dat is toch ook precies wat ik vertel? Er vindt inderdaad daadwerkelijk disk-corruptie plaats na een RAM bitflip. Dat is niet de discussie.

De discussie is wat er daarna gebeurt. Dus als je bij een scrub of wat de corruptie door RAM tegenkomt - want de RAM bitflip zelf gaat ZFS ongemerkt voorbij. ZFS ziet de corruptie pas als je een volgende keer de corrupte data weer tegenkomt. Dan kan uit de overige bronnen (pariteit, ditto blocks) er recovery plaatsvinden van het getroffen corrupte block.

In geval dat de checksum zelf verkeerd wordt aangemaakt, raakt je file stuk en kun je dit in de output zien. Indien het metadata betreft loop je inderdaad een risico op verlies van structuur. Dit valt allemaal in mijn grote post onder punten van uitzonderingen te lezen.

Maar mijn hele punt draait om de detectie. Kortom, de volgende keer dat je de data tegenkomt, wordt hoe dan ook die corruptie door RAM bitflips gedetecteerd. Of de checksum zelf is niet goed of één of meerdere data-blokken komen niet met de checksum overeen. Eén van de twee. Beide betekent detectie en in het laatste geval is recovery mogelijk. Dit heb ik zelf met een praktijktest aangetoond. En kan iedereen zelf reproduceren door hetzelfde experiment uit te voeren als ik heb gedaan.

De vraag die resteert is wat dit betekent voor de thuisgebruiker versus de Enterprise-gebruiker.

Voor de thuisgebruiker:

• De duidelijkheid over welke data wél en welke data níet corrupt is. Kortom, zekerheid. Als ZFS na één of twee scrubs zegt dat je data prima is, dan is dat ook zo.
• Kans dat non-ECC geheugen je files opvreet is zeer klein op een redundante array. We spreken over misschien één bitflip per maand hooguit. Want vergeet niet dat de duty cycle voor RAM bij thuisgebruikers héél laag is. 1% ofzo. Dus een bitflip per 25 maanden zou prima kunnen. Exacte cijfers heb ik niet; ik gok maar wat.
• Kans dat non-ECC geheugen je hele pool in een zwart gat stopt is astronomisch klein gezien het gebrek aan een voorbeeld op internationale fora. Er is geen concreet geval bekend waarbij dit ten grondslag zou liggen aan een gefaalde pool - iets wat sowieso zeer zeldzaam is bij ZFS, afgezien van massale disk failure.
• Als er wat stuk gaat kan de gebruiker simpelweg zien om welke files het gaat en deze opnieuw downloaden of genereren indien mogelijk. En zo niet, nou dan weet je wat je kwijt bent. Dat alleen al is zo waardevol. Stel je legacy RAID array klapt dan weet je ook de file structuur niet meer. Je weet helemaal niet meer wat je mist dan, dat lijkt mij nog het ergste.
• Kosten voor non-ECC systeem zijn beduidend lager. Soms slechts de helft. De kosten zijn doorgaans een zeer belangrijke factor voor thuisgebruikers. Velen van hen hebben geen budget voor een 1:1 backup van hun bulk data. Kortom, de drempel om wél ECC aan te schaffen is voor thuisgebruikers veel groter dan bij Enterprise, waarbij de meerprijs voor ECC - sowieso al een harde eis - teniet wordt gedaan voor alle andere dure hardware en redundante voedingen en allemaal duur via zakelijke kanalen en dan heb ik het nog niet over de service contracten (SLA's). Bij elkaar opgeteld is de meerprijs van ECC misschien 0,5% ofzo. Bij de thuisgebruiker tot 50%. Dus een factor 100 verschil.

Voor de Enterprise-gebruiker:

• Geen bescherming voor de kernel en applicaties zelf. Dus die kunnen compleet gekke dingen gaan doen zonder enige aantoonbare oorzaak. Zeer ongewenst!
• Data op een ZFS pool kan defect raken - dus permanent onleesbaar - en daarmee ook niet langer beschikbaar (availability). Kunnen we oplossen met High Availability. Geen groot probleem.
• Corrupte data kan naar applicaties worden gestuurd. Dit is de killer. Dit is funest! Je applicaties krijgen doodleuk verkeerde data aangeleverd en de kans is groot dat de applicatie in veel gevallen die corrupte data ook als zodanig zou verwerken. Een kleine verandering in het rekennummer of het bedrag bij een banktransactie. Het is ondenkbaar. Bedrijven hebben zekerheid nodig. Dus ECC is een absolute noodzaak. Hier struikelt het hele non-ECC voor enterprise verhaal.

[FireDrunk]

_{Goh, laat ik ook eens een duit in het zakje doen...}

Anoniem: 15758 schreef op dinsdag 23 juni 2015 @ 18:23:
[...]

Maar dat is toch ook precies wat ik vertel? Er vindt inderdaad daadwerkelijk disk-corruptie plaats na een RAM bitflip. Dat is niet de discussie.

De discussie is wat er daarna gebeurt. Dus als je bij een scrub of wat de corruptie door RAM tegenkomt - want de RAM bitflip zelf gaat ZFS ongemerkt voorbij. ZFS ziet de corruptie pas als je een volgende keer de corrupte data weer tegenkomt. Dan kan uit de overige bronnen (pariteit, ditto blocks) er recovery plaatsvinden van het getroffen corrupte block.

Das niet waar.. Je bitflip kan ook voorkomen in geheugen wat nog niet naar je filesystem geflushed is. (denk aan Samba buffers). Op het moment dat samba daarna een flush/sync geeft gaat zfs op dat moment pas een checksum berekenen, en kan je data corrupt op disk komen te staan.

Hoe groot die kans is, staat even niet ter discussie. Pertinent zeggen dat ZFS altijd corruptie ziet is kletskoek.

In geval dat de checksum zelf verkeerd wordt aangemaakt, raakt je file stuk en kun je dit in de output zien. Indien het metadata betreft loop je inderdaad een risico op verlies van structuur. Dit valt allemaal in mijn grote post onder punten van uitzonderingen te lezen.

Maar mijn hele punt draait om de detectie. Kortom, de volgende keer dat je de data tegenkomt, wordt hoe dan ook die corruptie door RAM bitflips gedetecteerd.

Dit is dus gewoon niet waar...

*grote knip*

Mijn visie is veel simpeler dan die van jullie allemaal (en eigenlijk ook wat Q soms zegt...).
De volgorde is niet:

*) ECC
*) Checksum Filesystem

De volgorde is wel:

*) Training volgen / inlezen / zelfstudie over goed beheer.
*) Hardware kiezen die bij je budget passen.
*) Nadenken of je niet beter een paar tientjes extra aan een goede voeding en goede koeling kan uitgeven.
*) BACKUPS MAKEN
*) offsite backups maken
*) Automatisch backup verificatie maken
*) Automatische mailing bij fouten maken
*) Een UPS. (Blikseminslagen komen vaker voor dan bitflips)
*) Een checksum filesystem
*) Een nog duurder stuk hardware kopen wat gemaakt is om 24/7 te draaien.
*) Automatisch een tweede offline offsite backup maken.

En waar past ECC in dit rijtje? Waar je zelf wil... Het is maar net waar jij de treep trekt: En nu moet ik meer uitgeven om meer zekerheid voor mijzelf te kweken...

Zeggen dat ECC nodig is vanwege harde berekeningen of resultaten die door mensen geroepen worden is koffiedik kijken. Zo simpel is het...

Ik geloof nog eerder astrologie dan kansberekeningen over het falen van computerhardware...

Als jij ECC wil om goed te slapen prima. Wil je het niet. Ook prima. Enige advies wat ik kan geven:
Neem deze beslissing los van ZFS. ECC is niet verplicht icm ZFS (zoals Q doet vermoeden), maar het helpt wel...

Andersom ook... ECC helpt ook bij NTFS... ECC helpt ook bij FAT32... ECC helpt zelfs bij TMPFS

_{Via mijn werk heb ik laatst bezoek gehad van 1 van de dev's van OpenZFS, en die zei ook: ECC is niet verplicht bij het gebruik van ZFS. Maar uiteraard helpt het wel. ZFS en ECC aan elkaar verbinden is gewoon plain-wrong...}

[ Voor 6% gewijzigd door FireDrunk op 23-06-2015 19:30 ]

[Anoniem: 15758]

FireDrunk schreef op dinsdag 23 juni 2015 @ 19:27:
Das niet waar.. Je bitflip kan ook voorkomen in geheugen wat nog niet naar je filesystem geflushed is.

Kortom, bovenaan mijn lijst van uitzonderingen, punt nummer één?

Bovendien praat je dan over enkele megabytes ten opzichte van vele gigabytes. De kans dat een bitflip ZFS data betreft is natuurlijk vele malen hoger. Bitflips in actieve data, zoals je kernel etc. kan in veel gevallen ook voor een crash zorgen. Het zijn de gevallen waar het zaakje blijft draaien en het helemaal fout gaat waar je voor moet vrezen.

Dat risico bestaat zeker. Daarom is ECC op alle systemen ook zeer wenselijk. Maar dat hoeft nog niet te betekenen dat het een verdubbeling van het budget waard is voor veel thuisgebruikers die een ZFS NAS willen.

Hoe groot die kans is, staat even niet ter discussie. Pertinent zeggen dat ZFS altijd corruptie ziet is kletskoek.

ZFS zal uiteindelijk alle corruptie zien van data die het ooit heeft opgeslagen. Ofwel de checksum komt niet overeen, ofwel de data komt niet overeen met de checksum. Zodra het (corruptie-vrij) in de handen van ZFS is, heb je dus een bepaalde mate van zekerheid. Je weet welke data goed is en welke niet.

Dit is dus gewoon niet waar...

Wellus

Mijn visie is veel simpeler dan die van jullie allemaal (en eigenlijk ook wat Q soms zegt...).
De volgorde is niet:

*) ECC
*) Checksum Filesystem

De volgorde is wel:

*) Training volgen / inlezen / zelfstudie over goed beheer.
*) Hardware kiezen die bij je budget passen.
*) Nadenken of je niet beter een paar tientjes extra aan een goede voeding en goede koeling kan uitgeven.
*) BACKUPS MAKEN
*) offsite backups maken
*) Automatisch backup verificatie maken
*) Automatische mailing bij fouten maken
*) Een UPS. (Blikseminslagen komen vaker voor dan bitflips)
*) Een checksum filesystem
*) Een nog duurder stuk hardware kopen wat gemaakt is om 24/7 te draaien.
*) Automatisch een tweede offline offsite backup maken.

Voor Enterprise-gebruikers ja. Voor thuisgebruikers slaat je verhaal nergens op.

Oh en je bent een atoombunker vergeten voor de nukes van Putin. En tja, als je toch bezig bent, waarom niet meerdere off-planet locaties in het universum?

Ook lichtelijk ironisch dat je jouw kijk op de zaak 'simpel' noemt. Voor een thuisgebruiker zijn die stappen die noemt alleen al reden genoeg om ZFS te laten zitten en een Synology te nemen. En daar is dus waar het mis gaat. Beginners worden afgeschrikt door mensen die gelijk alles goed willen doen volgens hun eigen overtuiging. En dat is hun goed recht. Dan hebben die mensen het gewoon perfect geregeld. Enterprise-class data protection. Maar thuisgebruikers hebben die tijd en energie veelal niet. Een ZFS NAS biedt al zoveel vooruitgang in zekerheid over je data dat al het andere slechts een extra schepje erbovenop is. Dus in die zin is het omdraaien van de volgorde (eerst ECC dan ZFS) in mijn ogen complete onzin. In elk geval - voor de thuisgebruiker. Bij Enterprise klopt een dergelijke stelling wel.

[FireDrunk]

Ik snap je punt, en mijn lijst is inderdaad te lang. Wat ik vooral bedoelde (maar niet zei) was:

Maak eerst goede backups, en kies daarna voor een checksum filesystem, en daarna voor ECC.
Mocht je door een unieke combinatie van fouten je hele pool kwijtraken, kan je een restore doen.
Als je nooit ook maar 1 file wil kwijtraken, neem je ECC.

Persoonijk vind ik een UPS en ECC gelijk staan.

[Anoniem: 15758]

Maar backups maken - waarvan dan? Als je Ext4 of NTFS gebruikt als filesystem, hoe weet je dan of je backup niet gecorrumpeerd is? Ik heb in mijn lange post in het begin van dit topic het scenario geschetst van het contamineren van backups doordat corruptie vrolijk kan doorstromen naar je backups.

Nu is dat met een non-ECC ZFS NAS ook zo! Maar dan tenminste zal je er achteraf bij een eerstvolgende scrub tegenkomen op de hoofdpool. En dat kan reden zijn om de incremental backup op de backup pool terug te draaien of opnieuw te doen. Kortom, de gebruiker kan ingrijpen - omdat de detectie goed werkt.

Ik zou dus stellen dat je in de volgorde eerst een 3e generatie filesystem wilt hebben die corruptie niet meer ongemerkt voorbij laat. Pas dan hebben backups pas echt goed zin, vooral als het incremental backups zijn waarbij je terug kan in de tijd.

In jouw situatie zou je wel ECC en een UPS kunnen hebben maar toch keihard ongemerkte corruptie op je driedubbel gebackupte trouwfoto's. Lange tijd niet bekeken, geen filesystem die de corruptie onder de aandacht kan brengen en de oudere incremental backups zijn reeds (geautomatiseerd) verwijderd. Geen detectie = dodelijk, want het probleem wordt niet ontdekt voordat het te laat is.

Ik snap ook niet wat je bedoelt met dat je een UPS gelijk vindt aan ECC-geheugen. Wat heeft een thuisgebruiker aan een UPS? Availability is helemaal niet belangrijk voor thuisgebruikers. Kan prima ff down. Bovendien heb je er weinig aan dat je server up is maar je desktops down en je dus netto niets met de server kunt doen. Tenzij je een UPS voor alles neemt natuurlijk.

Dus ECC zou ik als veel belangrijker inschatten voor een thuisgebruiker. Dat is de grap, ik ben juist helemaal voor ECC. Elk systeem zou ECC RAM moeten hebben. Ik vind het alleen realistisch dat thuisgebruikers regelmatig kiezen voor non-ECC geheugen; voor hun build is de meerprijs gewoon stevig en de gebruiker kiest in veel gevallen liever voor de goed beheersbare risico's die je loopt bij een non-ECC NAS, zoals een paar files stuk. Maar de zekerheid die ZFS biedt, gaat daardoor niet verloren.

[jacovn]

Ik ben om, ga mijn wintel pc ombouwen naar systeem met ecc geheugen. Zal mij geen corrupte file meer opleveren die ik na jaren pas tegenkom.
Moet ik ook maar refs gaan gebruiken, wordt het nog veiliger

supermicro moederbord met Xeon uit de V&A: 175 euro.
4x4 GB ECC ram van supermicro approved list uit de V&A: 80 euro

Dat valt nog mee

[ Voor 25% gewijzigd door jacovn op 24-06-2015 09:45 ]

[begintmeta]

Anoniem: 15758 schreef op dinsdag 23 juni 2015 @ 18:23:.
... de kans is groot dat de applicatie in veel gevallen die corrupte data ook als zodanig zou verwerken....

En dat zou natuurlijk niet mogen, een applicatie moet de logische en fysieke integriteit van de gegevens bewaken, tenslotte kan de data ook corrumperen door bijvoorbeeld een bitflip in het ram van de applicatie (in comes ecc-ram natuurlijk), door bugs in de software (applicatie zelf of ander programma) of bugs in bijvoorbeeld de cpu, door gebruikersfouten etc. Een deel is natuurlijk te ondervangen buiten de applicatie door een filesystem, maar volgens mij niet alles.

[ Voor 10% gewijzigd door begintmeta op 24-06-2015 00:03 ]

[Anoniem: 15758]

@begintmeta
Je applicatie gaat over zijn eigen data. Maar eenmaal aangeleverd aan het filesystem is het de taak van het filesystem deze foutloos aan de applicatie terug te geven wanneer deze daarom vraagt. Ik snap niet goed waar je naartoe wilt met het door elkaar laten lopen van verantwoordelijkheden.

Enig concreet voorbeeld dat ik ken is de journaling die sommige commerciële databasepakketten inzetten om de integriteit van hun database te bewaken. Maar dat is meer een noodoplossing omdat de systemen waarop deze software wordt gebruikt geen geavanceerde filesystems bieden die dit voor ze doet. ZFS is eigenlijk het enige echt bruikbare next-gen filesystem dus logisch dat zij zelf iets gaan knutselen. Maar dat is hacky en binnenkort niet meer nodig als alle platform over gaan op 3e generatie filesystems.

[begintmeta]

Wat ik bedoel is dat een applicatie toch sowieso de logische en fysieke integriteit van de data zou moeten bewaken, ook als het filesystem de fysieke integriteit van de opgeslagen data in het filesystem kan garanderen (of in ieder geval bewaken), want er zijn nu eenmaal meer redenen dat die integriteit kan zijn aangetast zoals ik had aangegeven. Een filesystem heeft daar niet in alle gevallen controle over.

Als een applicatie dus zijn werk zou doen en de logische en fysieke integriteit van de data zoals in het applicatiegeheugen aanwezig zou controleren/waarborgen (wat vziw vrijwel nooit het geval is), wordt controle van de fysieke integriteit van de applicatiedata door het filesystem redundant. Niet dat het daarmee slecht is, maar eventueel wel verspilling van resources. Maar in de praktijk is het natuurlijk meestal niet redundant, en daarom begrijp ik wel dat bij zfs, refs, hammer, btrfs... gekozen is voor het bewaken van integriteit van data (applicatiegegevens) naast metadata (/filesystemgegevens)

Nog een voorbeeld naast de eerder gegeven: denk aan dat de user 'per ongeluk' met een andere applicatie (hex-editor bijvoorbeeld) de file beschadigd, het filesystem heeft daar geen zicht op, de applicatie kan dat wel hebben.

Je komt er hoe dan ook niet omheen dat een applicatie de logische en fysieke integriteit zou moeten bewaken, dat dat niet gebeurt en dat een filesystem (en ecc-ram) dan gelukkig het een en ander kan opvangen doet er niets aan af dat dat eigenlijk redundant zou moeten zijn, integriteit moet niet alleen 'on disk/in filesystem' worden gecontroleerd maar ook daarvoor en daarna.

[ Voor 25% gewijzigd door begintmeta op 24-06-2015 01:46 ]

[Q]

Anoniem: 15758 schreef op dinsdag 23 juni 2015 @ 18:23:
[ Bij elkaar opgeteld is de meerprijs van ECC misschien 0,5% ofzo. Bij de thuisgebruiker tot 50%. Dus een factor 100 verschil. [/list]

Een eerlijkere voorstelling van zaken is dat je verteld dat het prijsverschil zo rond de 100 - 150 euro is voor een ECC-setup. Dus gebruik absolute bedragen. De een vind dat te duur, de ander heeft het er voor over.
Bovendien ga je voorbij aan leuke doosjes zoals de HP Proliant Gen8 die een heel leuk zelfbouw platformpje bieden. Een ECC setup kan heel betaalbaar zijn.

Dus niet zo overdrijven.

Je kunt het natuurlijk ook anders uitleggen. Als een NAS 5 jaar mee gaat dan kost een ECC setup - voor 150 euro extra - je 30 euro op jaarbasis of 2.5 per maand waardoor je geen risico meer loopt at rot geheugen de boel verstiert.

Lijkt mij heel schappelijk.

Je doet alsof die meerprijs zo'n drama is, maar dat moeten mensen zelf maar uitmaken. Als ze toch zonder
ECC willen draaien maar wel ZFS willen gebruiken, prima, als ze dat maar goed geïnformeerd doen.

Je doet er echter alles aan om de noodzaak van ECC geheugen te down-playen terwijl het hele fucking internet er van afhankelijk is, en de risico's die ZFS afdekt enorm te vergroten.

Wat betreft het concept dat rot geheugen pools om zeep kunnen helpen: de FreeNAS forums geven voorbeelden, maar die veeg jij natuurlijk zo van tafel. Er was er een op Reddit (/r/everythingzfs). ECC kan een hoop ellende voorkomen.

Zonder ECC is silent data corruptie gewoon nog steeds mogelijk en kan plaatsvinden iedere keer dat data op het systeem wordt geplaatst. Geldt ook voor andere file systems, maar ZFS is dus niet een magische oplossing voor alle problemen.

Ontken je dat ZFS het geheugen als kladpapier blind vertrouwd om haar eigen data structuren op te (herberekenen) en dat zo dus - alle checksumming ten spijt - het helemaal mis kan gaan?

Je hamert zo op detectie, maar ik ben zelf meer van preventie. Voorkomen is beter dan genezen. Met disks is dat moeilijk, maar met geheugen kan dat wel.

[ Voor 55% gewijzigd door Q op 24-06-2015 02:02 ]

[AndreStarTrek]

Ik ben met Q eens, de meer prijs van ECC is maar zo weinig en natuurlijk hangt dat ook af wat voor setup je maakt. Maar zodra je voor een setup ga van meerdere disks dan zit daar vooral de prijs.

Ik heb een maand geleden een FreeNAS box gemaakt:

Mainboard: Supermicro X10SL7-F
Processor: Intel Pentium G3440 @3.30GHz
Memory: 2x 8GB (16GB Total) Crucial DDR3 1600 1,35v DR x8 ECC UDIMM 240p (CT102472BD160B)
Pool: 11x4TB RaidZ3 (Toshiba HD SATA 64MB MD04ACA400 7200rpm)

Met zo setup stelt de meerprijs van ECC helemaal niks voor. Maar als ik daar mee andere ellenden hoe klein het mag wezen kan voorkomen dan zijn die paar tientjes die het meer gekost heeft zijn geld dubbel en dwars waard.

[ Voor 27% gewijzigd door AndreStarTrek op 24-06-2015 08:47 ]

[begintmeta]

IMHO is ECC ook wel de prijs waard. Voor mijn eigen thuisservertje (geen fileserver) heb ik het echter niet genomen (een J1900-bord zonder ondersteuning gekozen ipv een C2750 of C2550-bord), heb daar wel spijt van, een J1900 met ECC was het mooist geweest, maar ik vond een C2750 gewoon overkill. Voor mijn desktop heb ik ook ECC genomen, laptops ondersteunen helaas meestal niet.

[ Voor 29% gewijzigd door begintmeta op 24-06-2015 10:26 ]

[AndreStarTrek]

begintmeta schreef op woensdag 24 juni 2015 @ 08:56:
IMHO is ECC ook wel de prijs waard. Voor mijn eigen thuisservertje (geen fileserver) heb ik het echter niet genomen (een J1900-bord zonder ondersteuning gekozen ipv een C2750 C2550-bord), heb daar wel spijt van. Voor mijn desktop heb ik ook ECC genomen, laptops ondersteunen helaas meestal niet.

Ik ben voor mij volgende system ook aan het overwegen ECC te nemen. Ik vraag me sterk af hoeveel van de bsd's die je krijg of raar werken de Windows volkomen kan worden met ECC. Enige wat me tegen houd is, had begrepen dat veel consumenten borden geen ECC op werkt of niet werkt zoals het zou moeten. Maar dat is op dit moment niet meer dan klok horen luiden....... ik moet dus nog op onderzoek uit.

Krijg iedergeval zo langzamer hand genoeg van om geen ECC te gebruiken, hoe meer geheugen je in het systeem stop hoe groter de kan is dat je een bitflip krijg.

[ Voor 9% gewijzigd door AndreStarTrek op 24-06-2015 09:30 ]

[begintmeta]

Een bitflip hoeft natuurlijk op zich in veel gevallen helemaal geen problemen op te leveren. En ik vang het een en ander nu op door om de zoveel tijd gescript bestanden te vergelijken/integriteit te testen.

Maar IMHO zou elke applicatie dit automatisch moeten doen, dan heb je nooit onopgemerkt problemen. ECC maakt het voor alle software, inclusief filesystems, makkelijker om integriteit te bewaken, omdat ze daardoor wat minder wantrouwig tegenover het ram moeten staan.

[Kortfragje]

Ik ben het hierin heel erg met Q en Firedrunk eens.

ECC is een van die zaken die toevoegen aan een betrouwbaarder data opslag. Hoeveel gewicht je eraan hangt en hoeveel je ervoor over hebt moet eenieder zelf weten.

Ik weet wel dat voor mijn AMD X3 + Asus mobo is ECC heb genomen voor misschien 50 euro meer dan zonder.

Een aantal van mijn keuzes:

• Ik zou liever een offsite backup hebben dan ECC als ik moest kiezen.
• Ik zou liever ZFS draaien zonder ECC dan ext4 met ECC
• Ik heb liever een UPS voor clean shutdown dan ECC

Omdat ik die allemaal heb, heb ik ervoor gekozen ook ECC te kopen. Ik heb hier geen spijt van en het is me de investering meer dan waard.

[Q]

Voor mij gaat het veel meer om het concept.

De kern van CiPERS betoog is dat zelfs zonder ECC-geheugen ZFS een risico afdekt en dus zo het algehele risico verkleint.

CiPHERS argument is: je hebt 1/2 risico's afgedekt en at is beter dan 0/2.

Wat wordt ontkent is dat de complexiteit die aan ZFS ten grondslag ligt een verhoogd risico met zich mee brengt dat de pool verloren gaat bij rot geheugen. In mijn beleving krijg je een beetje 1/3.

Verder moeten mensen wel vertrouwd zijn met Linux/BSD om eventuele problemen op te kunnen lossen.

Als mensen menen zoals CiPHER dat dit niet waar is dat je pool stuk kan gaan bij rot geheugen, prima, dan ga je er netto op vooruit. Zeker als je voldoende skills hebt.

Op het moment dat je in je NAS geen ECC geheugen toepast, dan is data integriteit en beschikbaarheid gewoon niet je belangrijkste prioriteit. In die context is de vraag en noodzaak of je ZFS moet toepassen gewoon niet meer van belang. Het is wat mij betref met bovenstaande context prima als je ZFS met non-ECC toepast, maar als je dan voor NTFS / EXT4 kiest, ook goed. Je kunt dan beter je keuses baseren op waar je comfortabel mee bent.

Het argument dat je dan juist ZFS moet toepassen omdat die geheugen fouten 'detecteert' geeft forum bezoekers die minder in de materie thuis zijn een totaal verkeerde impressie van wat ZFS wel en niet kan en hoe het werkt. Dat kan een vals gevoel van veiligheid geven.

Voor thuis heb ik zelf veel meer vertrouwen in een oplossing met ECC geheugen en een legacy file system dan andersom. Op de schaal van thuis vind ik URE's niet zo'n issue en echt corrupte data die door disks wordt opgehoest: de kans dat je dit thuis meemaakt is zo klein.

We doen panisch over disks en er zitten wel risico's in de 'stack' maar ze passen zelf al zat error correction/detectie toe op allerlei lagen. In een thuis PC is met name het RAM geheugen wat onbeschermd is wat dat betreft.

[FireDrunk]

Je snijdt een goed punt aan. Een systeem is zo goed als de beheerder er van. Dat was ook punt 1.
Je hebt 100% gelijk over de complexiteit. Ik knoop dit niet vast aan risico.

Complexe systemen zijn niet automatisch risicovolle systemen. Dat jij dat als een risico ziet, is mijns inziens een mening. Maar ik snap heel goed dat je het ziet als een risico.

Kennis van je systeem is belangrijker dan een specifiek systeem gebruiken.

Je kan beter een goede beheerder achter een NTFS systeem zetten dan een slechte beheerder achter een ZFS systeem.

[TEB_Webbie]

Ik ben al enkele maanden met dit onderwerp bezig en heb ontdekt dat het risico eigenlijk best wel onderschat word. Maar het is inderdaad aan de gebruiker van deze systemen of je dit nodig denkt te hebben.
En of je het verlies van data door een fout op de koop toe neemt is voor ieder hun eigen keuze.
Ik zie dagelijks mensen een pc kopen en er 2 of meer 4 TB schijven of groter in zetten tot wel 16 Tb aan toe.
Waar ik dus al meerdere keren tegen aangelopen ben is dat deze mensen veel bestanden hierop zetten en er dan vanuit gaan dat deze veilig als backup kunnen dienen.
Dit is dus puur jezelf voor de gek houden, zelf heb ik nu al meerdere BDROM veiligheid kopie bestanden weg kunnen gooien omdat mijn raid5 NAS duidelijk faalt.

Tevens kwam ik erachter dat in mijn situatie dit vooral voorkomt op de seagate drives die ik heb in mijn systemen en nas boxen. Het kan ook puur pech zijn dat het bij mij vooral met de seagate drives is voorgekomen. Maar goed het punt is dat we steeds grotere en complexere systemen gaan gebruiken en daar kan dan zeker erg belangrijke data en/of bewijsmateriaal op staan.
Ik was zelf al begonnen om alle aankoop bewijzen op te slaan op mijn systemen en was druk bezig alle films en muziek die ik heb gekocht op te slaan als een image op mijn best wel vette nassen.
Wat je niet moet vergeten is dat het weinig lijkt maar als je nagaat dat ik al van zeker 21 bluray films een kopie heb en van mijn bijna 430 muziek cd's al aardig op weg was.
Dan praat ik nog niet over alle digitale foto's en thuis filmpjes die in de loop der jaren al ruim 5 Tb ruimte hebben ingenomen en daar komen er dagelijks wel weer wat bij.
Tot een paar maanden geleden dacht ik dat de het wel zou loslopen met die bitflip .....
Tot ik bij toeval ontdekte dat er iets vreselijk mis is gegaan met enkele bestanden.
De beide nas systemen draaien een 4 disk raid5 en dit lijkt veilig maar is het niet.
De film welke ik wou proberen te draaien vanaf een image op de nas blijkt een unrecoverable error te geven. Daarna heb ik al meerdere bestanden getest en inmiddels heb ik al meerdere bestanden gevonden die dus kaduuk zijn.
Natuurlijk heb ik nog de originelen dus zolang die niet beschadigd of onleesbaar worden heb ik nog geen probleem. Maar nu kom ik dan toch even terug op de bonnen en rekeningen die ik heb opgeslagen.
Dat lijkt onbelangrijk maar is het dus niet, veel van de ingescande documenten waren thermal prints.
Als je weet wat dat inhoud weet je ook dat deze al na het printen beginnen te vervagen.
Ook hier heb ik dus ontdekt dat het noodlot kan toeslaan ook al denk je is niet zo belangrijk ... zeg dat nog maar eens als je jouw dure produkten met 5 of 10 jaar garantie aan moet leveren met de originele factuur van aanschaf. En dan kijk je tegen die prachtige unrecoverable error aan... dus tsja jammer die 10 jaar garantie poooooooeeeeffff weg.
Ik heb op het werk altijd gewerkt met ecc werkstations en servers en wist wel dat dit beter was, maar de noodzaak voor thuis was er eigenlijk niet zo. Inmiddels zijn we op een punt beland dat het wel degelijk van belang kan zijn. In mijn geval weet ik nu al dat binnenkort overstap naar een machine met ecc en ondanks dat er een beetje prestatie verlies plaatsvind de integriteit van de opgeslagen bestanden wil garanderen.
Dat dit ook veel meer kost neem ik graag op de koop toe.
Momenteel ben ik driftig aan het kijken hoe ik de huidige nas systemen kan vervangen, dus ben meerdere opties aan het bekijken.
Enerzijds zijn er erg mooie afgedankte servers te koop met erg veel geheugen die mede kunnen dienen om als nas te dienen, waarmee ik mogelijk erg snel de huidige kan vervangen.
Het nadeel van het maken van een ZFS nas is dat deze niet kan worden uitgebreid met nieuwe schijven. Je kunt degene die je al hebt wel vervangen met grotere schijven als die er zijn, maar goed dit vind ik dan wel weer een minpunt. want je kan niet zomaar even ongeveer 22 tot 80 Tb data even ergens anders opslaan. Dus aan dit geheel zitten nogal wat haken en ogen maar voor mij staat de keuze vast.
Vanwege op dit moment een beperkt budget zal ik moeten beginnen erg belangrijke data over te gaan zetten en zorgen dat al diegene die gebruik maken van de huidige oplossing tijdelijk een backup op andere media regelen. Daarna wil ik eigenlijk eerst mijn hoofd machines vervangen voor werkstations en zet ik alles voor spellen wel op een aparte spel machine. Daarnaast heb ik dan nog wel een enorme nas nodig welke de binnenkomende data voor anderen moet kunnen verwerken en opslaan.
Daar moet ik nog over nadenken waarmee en hoe ik dit het beste kan doen.
Ik loop dan tegen problemen aan waarin ik rond de 20 tot 30 drives kan inzetten en aansturen en ook worden ondersteund door freebsd/nas
Aangezien deze data niet van mij is en men ervan uitgaat dat deze data integer is wil ik dit ook gaan migreren naar een zfs nas. Dus denk dat ik er niet onderuit kom om 2 verschilende machines te moeten hebben.
Daarnaast heb ik enkele leuke zelfbouw machines gezien welke tot wel 20 drives hadden.
Zelf zal ik dan ook minstens moeten denken aan 12 of meer drives.
Naar mijn budget kijkend zal ik momenteel even met minder genoegen moeten nemen vanwege een heleboel verbouwingen en aanpassingen aan onze woning.

Dus nog genoeg te doen.
Helaas doe ik de laatste jaren zelf niet veel meer op beheer gebied gedaan en heb ik mij niet kunnen verdiepen in het goed opzetten van een esxi server of san. Mede ook omdat zowat alles word uitbesteed aan derden.
Dus goed advies neem ik zal ik zeker overwegen, inmiddels heb ik al wel een budget kast gevonden waar ik 20 drives in kwijt zou kunnen. Dus nu nog afwegen wat ik nodig heb om de huidige snel te kunnen vervangen of dat ik beter ga doorsparen en een hele grote nas bouw welke beiden zaken in een machine kunnen onderbrengen. En dan rest er nog een nieuwe/andere ups te vinden want de huidige is aan vervanging toe.
De keuze daarin is pittig en het gaat dan om een redelijk grote aanschaf. Op zich trekt het mij wel om een wat oudere server te nemen omdat deze snel kan worden gekocht tegen een redelijk bedrag. Deze zijn dan wel overkil qua geheugen en processoren maar dan heb je wel meteen een stevige doos. waar je tot en met 12 * 3.5 " drives in kwijt kan
Stroom gebruik neem ik dan op de koop toe, omdat je de snelle processoren niet echt zwaar zal belasten zal dit ook niet zo erg oplopen denk ik. Om eerlijk te zijn trekken mijn huidige machines toch ook een aardige slok vooral mij game machine lust nogal wat power met zijn 3 videokaarten
Gelukkig kan ik deze dan weer vervangen zo gauw de amd fury x te verkrijgen is. Ik denk dat dan mijn huidige 1600 watt psu dan eigenlijk ook een beetje overkill gaat zijn .
Maar goed mijn 3 stuks 1200+ watt voedingen gebruik ik wel weer om enkele zware werkstations te voeden . Deze zware jongens blijken bij laag verbruik dus niet meer te verbruiken dan nodig ( echte gold en platinum 80+ is de moeite waard als je een nieuwe koopt dat kan ik je garanderen)

[ Voor 8% gewijzigd door TEB_Webbie op 14-07-2015 01:33 ]

[Q]

Anoniem: 15758 schreef op woensdag 23 september 2015 @ 18:08:

Daar heb je dus met ZFS geen last meer van. Je kunt hooguit een hele file verliezen in het ergste geval - dan kun je die uit backup terughalen. Daarnaast verlies je End-to-End Data Integrity, dus je applicaties kunnen corrupte data aangeleverd krijgen. ECC op je server is niet voldoende, op alle workstations moet je dan ook ECC nemen. Mijn argument in dat topic was ook dat je op je workstation juist nog meer behoefte hebt aan ECC dan op de ZFS server zelf, want ZFS heeft zelf al bescherming terwijl je workstations helemaal niets hebben.

Ik vind het echt onverantwoord dat mensen - zeker in een context waar het om wetenschappelijke data gaat - opzettelijk - op basis van oneigenlijke argumentatie - worden weggestuurd van ECC-geheugen.

Het hele fucking internet en de IT-infrastructuur van ieder bedrijf draait server-side op ECC-geheugen en client-side op non-ECC geheugen. Het feit dat clients geen ECC-geheugen hebben is geen valide argument om ECC dan maar achterwege te laten op de server. ZFS beschermt niet tegen de risico's waar ECC-geheugen tegen beschermt. Hooguit kan ZFS alarm slaan dat er mogelijk iets mis is, maar dan is het al te laat, je data is corrupt. Voorkomen is beter dan genezen.

Dat heb ik hier al toegelicht:

Q in "Het grote DIY RAID NAS topic deel 3"
Q in "Het grote DIY RAID NAS topic deel 3"

Als je om data integriteit geeft dan is ECC geheugen een must-have. Je kunt niet eens een server kopen van Dell HP of Supermicro die geen ECC geheugen ondersteund en dat is met reden.

*knip* dit deel van de reactie van Q staat hier: Q in "Het grote DIY RAID NAS topic deel 3"

[ Voor 22% gewijzigd door Anoniem: 15758 op 23-09-2015 23:41 ]

[Anoniem: 15758]

Q schreef op woensdag 23 september 2015 @ 22:11:
Ik vind het echt onverantwoord dat mensen - zeker in een context waar het om wetenschappelijke data gaat - opzettelijk - op basis van oneigenlijke argumentatie - worden weggestuurd van ECC-geheugen.

Het is uiteraard jouw mening dat dit 'oneigenlijke argumentatie' betreft - evenals dat dit 'opzettelijk' zou zijn. Daar heb ik verder geen behoefte om op te reageren. Het gaat mij puur om inhoudelijke argumenten.

Het hele fucking internet en de IT-infrastructuur van ieder bedrijf draait server-side op ECC-geheugen en client-side op non-ECC geheugen.

Dit argument mag waar zijn - alhoewel heel veel low-end servers ook geen ECC hebben - maar heeft geen directe relevantie voor het bouwen van een NAS voor thuis.

Het feit dat clients geen ECC-geheugen hebben is geen valide argument om ECC dan maar achterwege te laten op de server.

Dat wil ik dus bestrijden. Als je voor ECC gaat, ligt het voor de hand om dit op zowel de server als de clients te doen. Met als argument dat je alle corruptie vroeg of laat zult detecteren op de ZFS server, maar corruptie op de clients zul je niet detecteren en is dus veel kritischer.

ZFS beschermt niet tegen de risico's waar ECC-geheugen tegen beschermt.

En ECC beschermt je niet tegen risico's waar je ZFS je tegen beschermt. Ook dit argument is niet direct relevant voor de vraag de meerprijs van ECC het waard is voor een ZFS setup voor thuis.

Hooguit kan ZFS alarm slaan dat er mogelijk iets mis is, maar dan is het al te laat, je data is corrupt.

Klopt - daarom heb je van belangrijke data ook een backup. En als je ervoor kiest voor bepaalde datasets geen backup te hebben, is dat vaak een weloverwogen keuze. Bijvoorbeeld omdat de data vervangbaar is, zoals het opnieuw downloaden van de data. Maar ongemerkte permanente corruptie komt niet meer voor bij ZFS, ook niet bij gebrek aan ECC geheugen. Dat is voor thuisgebruikers het belangrijkst en daarom kunnen zij zonder ECC op de ZFS server - de client is een ander verhaal. Daarom mijn argument dat je eerst ECC op de client(s) zou moeten overwegen en pas als laatste op de server.

Voorkomen is beter dan genezen.

Mee eens - daarom zouden alle computers ook ECC moeten hebben en misschien zelfs nog meerdere lagen van bescherming. Maar gezien dat bedrijven als Intel aan productsegregatie doen en wilt dat mensen betalen voor de feature, moet je keuzes maken. Dan moet je dus de vraag stellen of de meerwaarde wel opweegt tegen de - onbetwiste - voordelen van ECC geheugen.

Als je om data integriteit geeft dan is ECC geheugen een must-have.

Niet mee eens. Je kunt 100% beschermd zijn zonder ECC geheugen op de server - mits de data die wordt aangeleverd door de clients wel corruptievrij is. Dus ECC op de clients en géén ECC op de server betekent dat je 100% beschermd bent. Want belangrijke data heb je sowieso een backup van, en zou er corruptie plaatsvinden dan kun je dit achteraf altijd zien. Dan val je dus terug op je backup. Zodoende heb je dataintegriteit voor de lange termijn altijd afgedekt. Voor de korte termijn - dus End-to-End Data Integrity - is ECC absoluut een must. Maar voor thuisgebruikers is dat niet zo heel belangrijk.

[begintmeta]

IMHO is het nog steeds zo dat men er, met het oog op end-to-end integrity, het meest bij gebaat zou zijn als de eindsoftware logische en fysieke integriteit van de data zou bewaken, uiteraard eventueel ondersteund door onderliggende software en hardware.

[Anoniem: 15758]

Dat punt heb je reeds gemaakt. Maar hoe zie je dat concreet voor je bij een applicatie zoals het SMB protocol? Dus een in Windows gemounte netwerkschijf (X:) die de gebruiker gebruikt om data op te zetten. Hoe moet SMB de integriteit van de data waarborgen? Als het zelf checksums van de data zou opslaan heb je het probleem van contaminatie als een andere client de data aanpast. Dus dit zou dan juist op de server moeten gebeuren, net als file locking.

Bovendien is denk ik het beste argument tegen jouw stelling, dat je de bergen software die eenmaal voorhanden zijn, niet zomaar kunt aanpassen. Je kunt wel de server met ZFS uitrusten en wel of geen ECC geheugen nemen. Die keuze heb je wel. Dus misschien heb je in specifieke situaties best een punt - zoals dat spellen bijvoorbeeld hun eigen integriteit voor game-data hebben - maar in zijn algemeenheid is het niet dekkend genoeg om veel invloed op de ECC-discussie te hebben, mijns inziens.

[Q]

Anoniem: 15758 schreef op woensdag 23 september 2015 @ 23:57:
[...]

Het is uiteraard jouw mening dat dit 'oneigenlijke argumentatie' betreft - evenals dat dit 'opzettelijk' zou zijn. Daar heb ik verder geen behoefte om op te reageren. Het gaat mij puur om inhoudelijke argumenten.

Dit argument mag waar zijn - alhoewel heel veel low-end servers ook geen ECC hebben - maar heeft geen directe relevantie voor het bouwen van een NAS voor thuis.

Mijn reactie was niet in de context van een NAS voor thuis maar voor iemand die wetenschappelijke data wil opslaan. Dan roepen dat ECC niet nodig is technisch onverantwoord.

Ik ben erg benieuwd naar low-end servers van HP, Dell en consorten die geen ECC ondersteunen. Zover ik weet worden die niet verkocht en bestaan die niet en dat is met reden.

Dat wil ik dus bestrijden. Als je voor ECC gaat, ligt het voor de hand om dit op zowel de server als de clients te doen. Met als argument dat je alle corruptie vroeg of laat zult detecteren op de ZFS server, maar corruptie op de clients zul je niet detecteren en is dus veel kritischer.

Dit is een onjuiste voorstelling van zaken.

Een ECC-workstation dat correcte data aanlevert aan een non-ECC server met rot geheugen kan resulteren in corrupte data on-disk *zonder* dat ZFS hier iets van door heeft.

En ECC beschermt je niet tegen risico's waar je ZFS je tegen beschermt. Ook dit argument is niet direct relevant voor de vraag de meerprijs van ECC het waard is voor een ZFS setup voor thuis.

Dat was helemaal niet de discussie. De discussie was dat als je data integriteit wilt, je gewoon ECC geheugen moet toepassen. Ik snap deze comment echt niet.

Klopt - daarom heb je van belangrijke data ook een backup. En als je ervoor kiest voor bepaalde datasets geen backup te hebben, is dat vaak een weloverwogen keuze. Bijvoorbeeld omdat de data vervangbaar is, zoals het opnieuw downloaden van de data. Maar ongemerkte permanente corruptie komt niet meer voor bij ZFS, ook niet bij gebrek aan ECC geheugen. Dat is voor thuisgebruikers het belangrijkst en daarom kunnen zij zonder ECC op de ZFS server - de client is een ander verhaal. Daarom mijn argument dat je eerst ECC op de client(s) zou moeten overwegen en pas als laatste op de server.

Ik heb hierboven al geïllustreerd dat data op een server met rot geheugen en ZFS nog steeds getroffen kan worden door silent corruptie die niet door ZFS kan worden opgemerkt.

Keer op keer lijkt je - in mijn ogen - niet te begrijpen dat ZFS fundamenteel - a priori / per definitie - niet kan beschermen tegen de gevolgen van rot werk geheugen, zoals ECC geheugen niet kan beschermen tegen rotte disks.

Ik hou niet zo van analogieën omdat mensen dan happen op de analogie.

Maar het lijkt alsof je redeneert dat als je gordels toepast, airbags niet meer nodig zijn, of vice-versa. Zowel gordels als airbags zijn samen veiliger dan iedere safety-measure op zichzelf. Omdat ze ieder verschillende risico's afdekken.

Het is waar dat beiden toepassen duurder is dan een van de twee zeker als een van de twee gratis is.

Mee eens - daarom zouden alle computers ook ECC moeten hebben en misschien zelfs nog meerdere lagen van bescherming. Maar gezien dat bedrijven als Intel aan productsegregatie doen en wilt dat mensen betalen voor de feature, moet je keuzes maken. Dan moet je dus de vraag stellen of de meerwaarde wel opweegt tegen de - onbetwiste - voordelen van ECC geheugen.

Mensen kunnen alleen die vraag beantwoorden als je ze juiste informatie voorschotelt en hun zelf een keuze laat maken, maar dat doe je zover ik kan zien niet. Jij denkt voor ze. En jij bepaalt in de andere discussies voor mensen wat ze duur en goedkoop moeten vinden. Maar jij kunt die afweging niet voor ze maken.

Niet mee eens. Je kunt 100% beschermd zijn zonder ECC geheugen op de server - mits de data die wordt aangeleverd door de clients wel corruptievrij is. Dus ECC op de clients en géén ECC op de server betekent dat je 100% beschermd bent. Want belangrijke data heb je sowieso een backup van, en zou er corruptie plaatsvinden dan kun je dit achteraf altijd zien. Dan val je dus terug op je backup. Zodoende heb je dataintegriteit voor de lange termijn altijd afgedekt. Voor de korte termijn - dus End-to-End Data Integrity - is ECC absoluut een must. Maar voor thuisgebruikers is dat niet zo heel belangrijk.

Dit is een aantoonbaar onjuiste voorstelling van zaken.

Correcte data van de client kan door rot werk geheugen op de server worden verhaspeld voordat ZFS zijn ding doet en je weet: garbage in = garbage out. Ga je een DB draaien op je server machine, precies het zelfde probleem. Operaties op data vinden plaats in werkgeheugen waarbij ZFS niet aan te pas komt en waar corruptie kan ontstaan.

Het is erg stom om op backups te moeten terug vallen terwijl corruptie of verlies van een file system eenvoudig voorkomen had kunnen worden.

Wat je reactie betreft over hoe intel qua business strategie omgaat met de toepassing en ondersteuning van ECC: dat is 100% niet van belang voor deze discussie.

[ Voor 8% gewijzigd door Q op 24-09-2015 00:42 ]

[Anoniem: 15758]

Q schreef op donderdag 24 september 2015 @ 00:33:
Dit is een onjuiste voorstelling van zaken.

Een ECC-workstation dat correcte data aanlevert aan een non-ECC server met rot geheugen kan resulteren in corrupte data on-disk *zonder* dat ZFS hier iets van door heeft.

Het kan tijdelijk resulteren in corruptie zonder dat ZFS dit door heeft. Het kan niet permanent resulteren in corruptie zonder dat ZFS dit door heeft. Uiteindelijk kan ZFS alle corruptie detecteren van de data die het krijgt aangeleverd. Als de data al corrupt was toen ZFS het in handen kreeg, is dat wel een punt. Vandaar mijn argument dat ECC op de client waardevoller cq. belangrijker cq. urgenter is dan ECC op de server.

Dat was helemaal niet de discussie. De discussie was dat als je data integriteit wilt, je gewoon ECC geheugen moet toepassen.

Dat is dus niet strict noodzakelijk indien het je puur om permanente corruptie te doen is en tijdelijke corruptie (dus verlies van End-to-End Data Integrity) mee te leven valt. Voor een grote groep ZFS gebruikers is dit van toepassing.

Keer op keer lijkt je niet te begrijpen dat ZFS fundamenteel niet kan beschermen tegen de gevolgen van rot werk geheugen

Kom dan met relevante argumenten?

Dit is een aantoonbaar onjuiste voorstelling van zaken.

Correcte data van de client kan door rot werk geheugen op de server worden verhaspeld voordat ZFS zijn ding doet

Als je bedoelt dat de data corrupt is voordat ZFS het in handen krijgt: prima; daarom dus ook ECC op de client. De server heeft meestal de beschikking over Sendfile, waardoor de geheugenlocaties gelijk blijven en ZFS dezelfde memory address gebruiken voor het inlezen van de data. Er vindt dus geen 2e memory copy plaats. Dus als ZFS de gegevens in handen krijgt, is deze of al corrupt (ECC op de client!) of deze is niet corrupt. In dat laatste geval kan deze alsnog corrupt raken als ZFS er mee werkt. Is dat het geval, dan zal ZFS - vroeg of laat - dit altijd detecteren.

Want ofwel de checksum wordt onjuist aangemaakt ofwel de (parity/stripe) data is incorrect. Beide gevallen worden gedetecteerd en in veel gevallen ook gecorrigeerd. Alleen het aanmaken van een foutieve checksum zou automatisch de gehele file afkeuren ook al is de on-disk data niet corrupt. Technisch kun je dan ook niet van permanente corruptie spreken omdat met tunables mogelijk is de zogenaamd maar dus niet corrupte gegevens alsnog aan de applicatie te leveren.

Het is erg stom om op backups te moeten terug vallen terwijl corruptie of verlies van een file system eenvoudig voorkomen had kunnen worden.

ECC beschermt maar tegen een extreem minuscuul aandeel van de risico's waar een backup tegen beschermd. Dat weet jij prima. Als de data belangrijk is, heb je een backup. Is deze dat niet, dan is simpelweg wéten dat de data corrupt is, genoeg bescherming voor 99% van de thuisgebruikers die ZFS overwegen. Dat is althans mijn insteek.

[Q]

Anoniem: 15758 schreef op donderdag 24 september 2015 @ 00:42:

Als je bedoelt dat de data corrupt is voordat ZFS het in handen krijgt: prima; daarom dus ook ECC op de client. De server heeft meestal de beschikking over Sendfile, waardoor de geheugenlocaties gelijk blijven en ZFS dezelfde memory address gebruiken voor het inlezen van de data. Er vindt dus geen 2e memory copy plaats. Dus als ZFS de gegevens in handen krijgt, is deze of al corrupt (ECC op de client!) of deze is niet corrupt.

Of de geheugen locaties gelijk blijven of niet maakt conceptueel niets uit. Rot geheugen maakt dat de client een 'A' aanlevert maar in het geheugen een 'B' komt te staan. ZFS kan dit niet afvangen of detecteren.

[Anoniem: 15758]

Dat maakt wel uit. Als de server geen Sendfile gebruikt, kunnen bitflips op de server ervoor zorgen dat:

A ) de client wel degelijk corruptievrije data heeft aangeleverd
B ) de netwerklaag ook geen fouten maakt
C ) de server bitflips ondervindt vóórdat ZFS de data in handen krijgt
D ) ZFS de corrupte data aangeleverd krijgt en deze corrupte data vervolgens beschermt.

Dan ben je dus de sjaak. Ook hier geldt dat ZFS de data beschermt die het in handen krijgt. Maar als deze al corrupt is om te beginnen, zijn alle beschermingslagen voor niets. Dit scenario hoeft dus niet door de client of de netwerklaag te komen; het kan ook door de server zelf komen indien deze geen Sendfile gebruikt. Daarom is dit relevant.

ZFS kan dit niet afvangen of detecteren.

Ik zal herhalen wat ik heb gezegd:

Het kan tijdelijk resulteren in corruptie zonder dat ZFS dit door heeft. Het kan niet permanent resulteren in corruptie zonder dat ZFS dit door heeft. Uiteindelijk kan ZFS alle corruptie detecteren van de data die het krijgt aangeleverd. Als de data al corrupt was toen ZFS het in handen kreeg, is dat wel een punt. Vandaar mijn argument dat ECC op de client waardevoller cq. belangrijker cq. urgenter is dan ECC op de server.

Als je denkt dat dit onjuist is, zul je met goede argumenten moeten komen; niet eromheen lopen. Kom met eigen tests, bijvoorbeeld, zoals ik zelf ook heb gedaan!

Daarnaast, bedenk ook dat zelfs met ECC geheugen je nog steeds bitflips kunt hebben die niet gedetecteerd worden. Want ECC is meestal: correct single bit error, detect double bit errors. Triple+ bitflips worden dus niet gedetecteerd en geldt hetzelfde verhaal als non-ECC geheugen. Ergo, met ECC blijft het hele risico bestaan, het risico wordt alleen kleiner.

Ten slotte wil ik opmerken dat nog nooit in de geschiedenis van mijn bestaan ik een concreet geval heb gehad van permanente corruptie door non-ECC RAM. Niet dat het nooit voorgekomen zal zijn, maar het is ook niet zo'n groot risico dat je dit daadwerkelijk aan den lijve ondervindt. In tegendeel: met behoorlijk brak RAM geheugen heb ik ZFS getest en daarbij is alle corruptie evengoed weer gecorrigeerd bij een 2e scrub met goed RAM geheugen. Laat staan dat bestanden afgekeurd werden omdat het niveau van corruptie te groot was. Het betrof hier geen test met non-ECC geheugen die af en toe een bitflip per 8 maanden genereert, maar een reepje dat tienduizenden bitflips per seconde genereerde, zoals getest met MemTest86+. Kortom, het risico is vrij marginaal.

[Q]

Scenario waarbij een client correcte data aanlevert aan een server met non-ecc geheugen dat rot is:

Voordat ZFS zijn checksums kan berekenen over data moet de data eerst ergens in het werkgeheugen worden opgeslagen voordat het naar disk gaat. Op dat moment treedt de corruptie al op en heeft het berekenen van checksums van ZFS al geen zin meer.

ECC beschermt maar tegen een extreem minuscuul aandeel van de risico's waar een backup tegen beschermd. Dat weet jij prima. Als de data belangrijk is, heb je een backup. Is deze dat niet, dan is simpelweg wéten dat de data corrupt is, genoeg bescherming voor 99% van de thuisgebruikers die ZFS overwegen. Dat is althans mijn insteek.

Jij weet ook prima dat veel data sets te groot zijn om te backuppen, maar dat het toch erg jammer zou zijn als alle data verloren gaat omdat er vaak een hoop tijd en moeite is gestoken in het verzamelen.

Een backup is vaak alleen realistisch van een sub-set van de data (foto's enzo). Dus thuis is een NAS met ECC in deze context bijna nog belangrijker dan bij een bedrijf.

Daarnaast, bedenk ook dat zelfs met ECC-geheugen je nog steeds bitflips kunt hebben die niet gedetecteerd worden. Want ECC is meestal: correct single bit error, detect double bit errors. Triple+ bitflips worden dus niet gedetecteerd en geldt hetzelfde verhaal als non-ECC geheugen. Ergo, met ECC blijft het hele risico bestaan, het risico wordt alleen kleiner.

Het hele risico wordt zo astronomisch super klein dat de hele IT-industrie het als een geaccepteerd risico beschouwt en hun mission-critical applicaties er aan toe vertrouwd. Dit lijkt mij een non-argument.

Het ene moment beaam je dat ECC-geheugen heel nuttig is en toegevoegde waarde heeft. Het andere moment kraak je het nut van ECC-geheugen totaal af zoals je hier boven doet omdat het niet 100% perfect is.

[ Voor 45% gewijzigd door Q op 24-09-2015 02:03 ]

[Hielko]

Of het belangrijk is hangt af van de kans dat het fout kan gaan. Zonder die verder te kwantificeren dan "in theorie" kan er corruptie optreden kom je niet ver om te bepalen of de extra kosten van ECC geheugen gerechtvaardigd zijn. Immers is er ook een theoretische kans dat de server geraakt wordt door bliksem (en nog een lading veel waarschijnlijkere dingen) maar dat betekent ook niet direct dat een backup een must have is.

[justice strike]

Stel ECC kost 150 euro extra. Dan zou ik bijna geneigd zijn om een extra systeem voor dat bedrag daar neer te zetten.

Overigens zou je beter een nieuw OS kunnen creeren om met faulty hardware om te kunnen gaan. zo ongeveer 80 procent van de hardware failures kun je met programmeren af vangen. Helaas bestaat zo'n OS naar mijn weten niet.

Overigens. Waarom allen over ECC geheugen praten? Als de processor rot is kan dat ook een bitflip veroorzaken, is wel eens vaker voorgekomen. (zelfde geld ook voor het moederbord)

[ Voor 21% gewijzigd door justice strike op 24-09-2015 13:18 ]

[begintmeta]

justice strike schreef op donderdag 24 september 2015 @ 13:13:
Stel ECC kost 150 euro extra. Dan zou ik bijna geneigd zijn om een extra systeem voor dat bedrag daar neer te zetten.

Overigens zou je beter een nieuw OS kunnen creeren om met faulty hardware om te kunnen gaan. zo ongeveer 80 procent van de hardware failures kun je met programmeren af vangen. Helaas bestaat zo'n OS naar mijn weten niet.

Er is vanalles mogelijk in software, en zoals ik al aangaf zou het in mijn ogen het beste zijn als applicaties de integriteit van hun data goed bewaken. Je moet je nu eenmaal bij de uiteinden controleren, je moet ze (evt by proxy) kunnen vergelijken. Data_{op t0} naar Data_{op t+x}. (het 'naar' kan allerlei stappen bevatten transport, opslag.... in die tijd/op of tussen die stappen kan corruptie om allerlei redenen optreden) Dat daar niet altijd even goed op wordt gecontroleerd kan ik me ook wel voorstellen, in die zin is het misschien ook wel begrijpelijk dat bepaalde stappen meer controle krijgen (trend naar data checksumming in recentere filesystems, grote hoeveelheden data lange tijd op redelijk gevoelige media), omdat de kans op falen vanwege niet bij elke station/elke stap even groot is.

Even zoeken leverde ook wel wat publicaties op over softwarematige aanpak trouwens: 'SoftECC : A System for Software Memory Integrity Checking', 'A Tunable, Software-based DRAM Error Detection and Correction Library for HPC' 'Detection and Correction of Silent Data Corruption for Large-Scale High-Performance Computing', 'Solving the software safety paradox' Maar alles in software doen lijkt me potentieel soms minder handig (of duurder) te kunnen zijn dan ook het een en ander in hardware doen.

Overigens. Waarom allen over ECC geheugen praten? Als de processor rot is kan dat ook een bitflip veroorzaken, is wel eens vaker voorgekomen. (zelfde geld ook voor het moederbord)

Vziw is het meeste (PCIe, CPU-cache, SATA...) in staat bitflips etc te corrigeren of tenminste te detecteren, maar er zijn natuurlijk ook zaken die lastig zijn (CPU-registers kan ik me voorstellen (zit meestal parity op, valt wel mee dus)). Wat je dan zou kunnen doen is alle bewerkingen meerdere keren (evt geinverteerd) uitvoeren, en dan vergelijken. Als je dan verschillen vindt, is iets misgegaan. (Maar ook hier is, blijkt uit een korte search, veel meer en vermoedelijk ook verstandigers over geschreven dan ik kan) Uiteindelijk is de kans gewoon best aanwezig (ook weer afhankelijk van de omstandigheden) dat in 32GB RAM eens een bitje flipt, die kans is ook groter dan dat dat gebeurt in 1GB RAM (bij verder dezelfde omstandigheden etc). Of je de gevolgen van zo'n incident de moeite van aanvullende hard of software waard vindt, is natuurlijk het resultaat van een uitgebreide afweging waarop diverse factoren invloed hebben.

[ Voor 33% gewijzigd door begintmeta op 24-09-2015 14:36 ]

[Q]

justice strike schreef op donderdag 24 september 2015 @ 13:13:
Stel ECC kost 150 euro extra. Dan zou ik bijna geneigd zijn om een extra systeem voor dat bedrag daar neer te zetten.

Overigens zou je beter een nieuw OS kunnen creeren om met faulty hardware om te kunnen gaan. zo ongeveer 80 procent van de hardware failures kun je met programmeren af vangen. Helaas bestaat zo'n OS naar mijn weten niet.

Overigens. Waarom allen over ECC geheugen praten? Als de processor rot is kan dat ook een bitflip veroorzaken, is wel eens vaker voorgekomen. (zelfde geld ook voor het moederbord)

We focussen op ECC-geheugen omdat de rest van de componenten redelijk goed worden beschermd met allerlei checksums en parity etc (ook de CPU). etc. RAM geheugen in consumenten hardware is hierop de grote uitzondering, terwijl er heel veel data doorheen gaat.

Wat betreft de CPU ben ik even niet meer up to date wat nu wel en niet wordt beschermd in consumenten vs xeon cpus.

Ik vond wel dit:

Wikipedia: ECC memory

Many processors use error correction codes in the on-chip cache, including the Intel Itanium processor, the AMD Athlon and Opteron processors, and the DEC Alpha 21264.[27][22]

As of 2006, EDC/ECC and ECC/ECC are the two most common cache error protection techniques used in commercial microprocessors. The EDC/ECC technique uses an error detecting code (EDC) in the level 1 cache. If an error is detected, data is recovered from ECC-protected level 2 cache. The ECC/ECC technique uses an ECC-protected level 1 cache and an ECC-protected level 2 cache. [28] CPUs that use the EDC/ECC technique always write-through all STOREs to the level 2 cache, so that when an error is detected during a read from the level 1 data cache, a copy of that data can be recovered from the level 2 cache.

Volgens mij zit parity/ecc bescherming op l1/l2/l3 cache al langer in processors, vanaf de jaren '90 maar ik kan er weinig over vinden.

[ Voor 39% gewijzigd door Q op 24-09-2015 14:58 ]

[justice strike]

Q schreef op donderdag 24 september 2015 @ 14:22:
[...]


We focussen op ECC-geheugen omdat de rest van de componenten redelijk goed worden beschermd met allerlei checksums en parity etc (ook de CPU). etc. RAM geheugen in consumenten hardware is hierop de grote uitzondering, terwijl er heel veel data doorheen gaat.

Wat betreft de CPU ben ik even niet meer up to date wat nu wel en niet wordt beschermd in consumenten vs xeon cpus.

Ik vond wel dit:

Wikipedia: ECC memory


[...]


Volgens mij zit parity/ecc bescherming op l1/l2/l3 cache al langer in processors, vanaf de jaren '90 maar ik kan er weinig over vinden.

nu focus je op de registers, maar er is meer dan alleen een register op de CPU. de alu's en fp's kunnen heel makkelijk bitflips veroorzaken. Bij GPU's wordt dit zelfs voor lief genomen om sneller data te kunnen processen.

[Q]

justice strike schreef op donderdag 24 september 2015 @ 15:15:
nu focus je op de registers, maar er is meer dan alleen een register op de CPU. de alu's en fp's kunnen heel makkelijk bitflips veroorzaken. Bij GPU's wordt dit zelfs voor lief genomen om sneller data te kunnen processen.

Je bent nu de discussie aan het verplaatsen van de cache registers naar de alu en fp's zelf. Dat het vermeende risico niet een issue is wordt bewezen door het feit dat onze gehele IT-infrastructuur wereldweid stabiel draait op genoemde apparatuur. Misschien dat mainframes er nog een stapje bovenop doen, maar dat is een gigantische outlier.

Dat er op een GPU bitflips mogelijk worden geaccepteert zal heel erg aan de context liggen en in hoeverre het relevant is om die flips af te vangen ergens verder op in de keten, zoals op applicatie niveau. Er worden ook GPUs verkocht met ECC geheugen.

justice strike schreef op donderdag 24 september 2015 @ 13:13:
Stel ECC kost 150 euro extra. Dan zou ik bijna geneigd zijn om een extra systeem voor dat bedrag daar neer te zetten.

Voor 150 euro heb jij geen 2e systeem neergezet en bovendien zie ik niet hoe je daar iets mee opschiet. Je neemt de risico's die ECC-geheugen afdicht er niet mee weg.

[ Voor 20% gewijzigd door Q op 24-09-2015 15:47 ]

[justice strike]

Q schreef op donderdag 24 september 2015 @ 15:38:
[...]


Je bent nu de discussie aan het verplaatsen van de cache registers naar de alu en fp's zelf. Dat het vermeende risico niet een issue is wordt bewezen door het feit dat onze gehele IT-infrastructuur wereldweid stabiel draait op genoemde apparatuur. Misschien dat mainframes er nog een stapje bovenop doen, maar dat is een gigantische outlier.

Het is natuurlijk niet zo belangrijk als je alu of fp een verkeerde waarde geeft in dagelijks leven. Bekend voorbeeld is de bug in de FPU in de pentium die door niemand was opgemerkt.

Is overigens ook de reden waarom NASA 'verouderde' CPU's.

Dat er op een GPU bitflips mogelijk worden geaccepteert zal heel erg aan de context liggen en in hoeverre het relevant is om die flips af te vangen ergens verder op in de keten, zoals op applicatie niveau. Er worden ook GPUs verkocht met ECC geheugen.

gpu geeft je een andere floating point, maar dat zorgt er dan voor dat je pixel groen is ipv rood. Dat is in een groter raster niet echt een probleem. Dat wordt overigens niet afgevangen door ecc geheugen omdat de bitflip in de gpu gebeurt.

[...]


Voor 150 euro heb jij geen 2e systeem neergezet en bovendien zie ik niet hoe je daar iets mee opschiet. Je neemt de risico's die ECC-geheugen afdicht er niet mee weg.

bitflips die voorkomen in 2 systemen in hetzelfde stukje geheugen? je ziet dan wel spoken denk ik.

[FireDrunk]

Volgens mij snap je Q's verdediging niet.

Als je 2 systemen met storage hebt, hoe synchroniseren die 2 dan dat de 1 een bitflip heeft, en de ander niet? En de vraag daarna als je er al achter komt dat 1 van de twee niet correct is, hoe weet je dan welke wel correct is?

Meer systemen lost het probleem van een bitflip nooit op...

[justice strike]

FireDrunk schreef op donderdag 24 september 2015 @ 16:16:
Volgens mij snap je Q's verdediging niet.

Als je 2 systemen met storage hebt, hoe synchroniseren die 2 dan dat de 1 een bitflip heeft, en de ander niet? En de vraag daarna als je er al achter komt dat 1 van de twee niet correct is, hoe weet je dan welke wel correct is?

Meer systemen lost het probleem van een bitflip nooit op...

Cluster software of synchronisatie software is makkelijk te krijgen. Daarbij zou ik zelf meer vertrouwen hebben in 2 naast elkaar draaiende systemen dan 1 systeem uitgerust met ecc.

Ik heb al vaak genoeg meegemaakt dat een CPU kapot en foute berekeningen maakt en/of een bug bevat of bijvoorbeeld HBA's rot raken oid. (dat is overigens tegenwoordig een stuk minder aan de hand dan 15 jaar geleden).

[dcm360]

Dan blijft de vraag: hoe bepaalt de cluster software welk bestand correct is, als node 1 zegt dat de inhoud van een bestand 'a' is, en node 2 zegt dat het 'c' is. Was het een bitflip op node 1, of een bitflip op node 2?

[begintmeta]

Dan kan je wel detecteren, niet corrigeren, als je nog een (of 99) systeem toe zouvoegen zou je kunnen stellen dat de meeste stemmen het bij het juiste eind hebben. Liefst natuurlijk systemen met verschillende cpus (bijvoorbeeld een Power en een x86-64 en een arm64 oid) Daarnaast kan je elk systeem ook nog eens softwarematig dezelfde bewerking herhaaldelijk laten uitvoeren en vergelijken. De detectiekans wordt dan groter, en je zou kunnen zeggen ook de correctiekans.

[Anoniem: 15758]

Q schreef op donderdag 24 september 2015 @ 01:29:
Scenario waarbij een client correcte data aanlevert aan een server met non-ecc geheugen dat rot is:

Voordat ZFS zijn checksums kan berekenen over data moet de data eerst ergens in het werkgeheugen worden opgeslagen voordat het naar disk gaat. Op dat moment treedt de corruptie al op en heeft het berekenen van checksums van ZFS al geen zin meer.

Daarom is het Sendfile verhaal dus relevant. Daarbij vindt er geen extra memory copy plaats. De netwerkadapter/driver plaatst de inhoud in het RAM geheugen en vanaf die plek neemt ZFS het over. Zonder Sendfile zit hier nog een extra memory copy tussen, en dan kan het dus voorkomen dat ZFS corrupte data in handen krijgt terwijl de netwerkadapter het wel correct heeft ontvangen.

Ook met Sendfile heb je nog de netwerklaag niet uitgesloten. Want adapters met TSO (TCP Segment Offload) en TOE (TCP Offload Engine) en RXCSUM en TXCSUM doen ook zaken intern hardwarematig in de netwerkchip zelf. Als deze geen ECC gebruiken of andere errorcorrecting mechanismes hebben, dan kan dus ook op netwerkniveau er corruptie plaatsvinden waardoor ZFS corrupte data in handen krijgt.

Maar, we concentreren ons hier specifiek op de kwestie dat ZFS wel correcte data in handen krijgt - mede dankzij Sendfile dus - maar bij de verwerking door ZFS er RAM corruptie plaatsvindt. Ik stel dus dat er geen mogelijkheid is dat ZFS de corruptie vroeg of laat nooit zou kunnen ontdekken. Bij een scrub met goed geheugen - wanneer er geen bitflips plaatsvinden - zal alle corruptie worden ontdekt. Ofwel de checksum klopt niet, ofwel de data klopt niet. In dat laatste geval kan ZFS met behulp van redundancy de corruptie ook meestal corrigeren.

Jij weet ook prima dat veel data sets te groot zijn om te backuppen, maar dat het toch erg jammer zou zijn als alle data verloren gaat omdat er vaak een hoop tijd en moeite is gestoken in het verzamelen.

Zeker. Maar als je nou de zekerheid hebt dat file X in die hele grote dataset corrupt is, dan heb je denk ik voldoende mogelijkheden om die opnieuw te downloaden of uit je backup te trekken. En als je toch de zekerheid wilt hebben dat alle bestanden de tijd overleven, moet je flink investeren in backups. Want ook met ECC op alle computers heb je maar een klein risico afgedekt terwijl alle andere risico's openstaan. Een backup blijf je nodig hebben voor belangrijke data.

Voor veel gebruikers is echter de wetenschap wanneer iets corrupt is of niet, al enorm waardevol. Zo waardevol dat de gebruiker er prima mee kan leven als onverhoopt toch een file stuk blijkt te zijn. De documenten en persoonlijke foto's van gebruikers worden meestal wèl gebackupped, omdat die dataset veel kleiner is dan de bulk dataset. De bulk blijft goed beschermd, met name door de detectie van corruptie.

Het hele risico wordt zo astronomisch super klein dat de hele IT-industrie het als een geaccepteerd risico beschouwt en hun mission-critical applicaties er aan toe vertrouwd.

Hetzelfde argument kun je aanvoeren om geen ECC te gebruiken voor thuissituaties. Het risico dat je belangrijke bestanden kwijtraakt is nihil, want je hebt een backup en je gebruikt veilige ZFS Send/Receive mechanismen om de integriteit van je backups te waarborgen. De detectie van ZFS doet zijn werk om je te informeren en de kans dat bestanden van je dataset die je niet backupt kapot gaan, is klein genoeg om de meerprijs van ECC te laten voor wat het is.

Het ene moment beaam je dat ECC-geheugen heel nuttig is en toegevoegde waarde heeft. Het andere moment kraak je het nut van ECC-geheugen totaal af

Ik marginaliseer het nut van ECC voor thuissituaties in de praktijk voor een goed geconfigureerde ZFS NAS - dus inclusief Sendfile bijvoorbeeld en bij gebruik van backups voor ècht belangrijke data waarbij je niet accepteert dat één file stuk kan gaan.

Maar, ik ben wel van mening dat geen enkele computer zonder ECC geheugen verkocht zou mogen worden. In dit tijdperk mag je verwachten dat computertechniek volwassen en extreem betrouwbaar is. Technisch gezien is dit prima mogelijk en de meerprijs is qua kostprijs insignificant. Maar de praktijk is dat bedrijven bepalen welke prijs daarvoor wordt gevraagd, en door allerlei vormen van productsegregatie (CPUs, chipsets, moederborden) is de uiteindelijke meerprijs voor ECC best significant - voor de thuisgebruiker in elk geval. Veel mensen hier overwegen een ZFS systeem van een paar honderd euro. Dat valt niet te vergelijken met de situatie van zakelijke gebruikers waar alleen de SLA-agreements al de prijs extreem opvoeren en de hardwarekosten daarbij in het niet vallen. ECC is absoluut een no-brainer daarbij en logisch dat geen enkel zakelijk systeem zonder ECC verkocht wordt. En terecht.

[justice strike]

dcm360 schreef op donderdag 24 september 2015 @ 17:42:
Dan blijft de vraag: hoe bepaalt de cluster software welk bestand correct is, als node 1 zegt dat de inhoud van een bestand 'a' is, en node 2 zegt dat het 'c' is. Was het een bitflip op node 1, of een bitflip op node 2?

dat is natuurlijk niet hoe een cluster werkt. overigens. Ik meen mij te herinneren dat ZFS over meerdere servers heen zou kunnen werken. Dan heb je nagenoeg al het probleem kleiner gemaakt

[Q]

Anoniem: 15758 schreef op donderdag 24 september 2015 @ 18:33:
Daarom is het Sendfile verhaal dus relevant. Daarbij vindt er geen extra memory copy plaats. De netwerkadapter/driver plaatst de inhoud in het RAM geheugen en vanaf die plek neemt ZFS het over.

En daar is precies waar het mis gaat. Sendfile is een performance maatregel, geen data security integriteit maatregel. Bovenstaande is precies het window waar het mis kan gaan en waarom ZFS niet tegen de gevolgen van rot werkgeheugen kan beschermen. Een extra copy zou het risico vergroten, maar dat maakt conceptueel niets uit.

Daarnaast speelt nog steeds het andere scenario waarbij ZFS natuurlijk RAM geheugen als kladpapier moet gebruiken voor al haar operaties en ook daar kan het mis gaan. Worst-case veries je je pool.
Dit is niet ZFS-specifiek en het risico is niet groot, maar het strookt niet met het beeld wat jij neer probeert te zetten dat ZFS een soort goddelijke oplossing is die alle risico's wegneemt en dat het ECC-geheugen effectief overbodig maakt.

Zeker. Maar als je nou de zekerheid hebt dat file X in die hele grote dataset corrupt is, dan heb je denk ik voldoende mogelijkheden om die opnieuw te downloaden of uit je backup te trekken.

ZFS kan in die zin helpen dat je vrij zeker kunt zijn dat een deel van je data die al on-disk stond voordat je geheugen problemen begonnen nog safe is. Maar alles wat daarna op het systeem is geplaatst, daarvan is de integriteit per definitie niet gegarandeerd. Garbage in, garbage out.

En als je toch de zekerheid wilt hebben dat alle bestanden de tijd overleven, moet je flink investeren in backups. Want ook met ECC op alle computers heb je maar een klein risico afgedekt terwijl alle andere risico's openstaan. Een backup blijf je nodig hebben voor belangrijke data.

Die 'andere' risico's benoem je niet, maar als je daarmee doelt op user error / brand / diefstal enzo, nee ECC-geheugen beschermt daar niet tegen. Maar dat was ook nooit de discussie.

De praktijk is echter dat mensen niet 2x een 40 TB NAS neerzetten omdat dit onbetaalbaar wordt. Het is beter om dan die ene 40 TB NAS die je neerzet zo robuust en stabiel mogelijk neer te zeten en ECC-geheugen helpt daarbij. Dat je dan natuurlijk een rest-risico loopt mag duidelijk zijn.

Maar dat maakt in deze context ECC-geheugen juist extra waardevol, juist omdat een volledige backup meestal niet een optie is.

Voor veel gebruikers is echter de wetenschap wanneer iets corrupt is of niet, al enorm waardevol. Zo waardevol dat de gebruiker er prima mee kan leven als onverhoopt toch een file stuk blijkt te zijn. De documenten en persoonlijke foto's van gebruikers worden meestal wèl gebackupped, omdat die dataset veel kleiner is dan de bulk dataset. De bulk blijft goed beschermd, met name door de detectie van corruptie.

Het probleem is dat je dus door silent corrutie via RAM niet weet wat er precies stuk is. Zeker als het euvel een tijdje onopgemerkt is gebleven. Wat on-disk staat is wel beschermd, maar niet wat er bij wordt geplaatst nadat de geheugen problemen ontstaan.

Hetzelfde argument kun je aanvoeren om geen ECC te gebruiken voor thuissituaties. Het risico dat je belangrijke bestanden kwijtraakt is nihil, want je hebt een backup en je gebruikt veilige ZFS Send/Receive mechanismen om de integriteit van je backups te waarborgen. De detectie van ZFS doet zijn werk om je te informeren en de kans dat bestanden van je dataset die je niet backupt kapot gaan, is klein genoeg om de meerprijs van ECC te laten voor wat het is.

We hebben hier al eerder over gesproken. ZFS gebruiken als detectie mechanisme van rot werkgeheugen is niet veilig en ook naar DIY bouwers toe wordt een vals gevoel van veiligheid gecreeerd.

Alhoewel het risico niet groot is, kan tevens ook je pool verloren gaan. Iedere write naar je file system kan potentieel de metadata van je pool omzeep helpen. Dat is niet eens specifiek voor ZFS. Andere file systems kunnen ook goed naar de kloten worden geholpen. Maar het is een risico wat met ECC-geheugen wordt weggenomen.

Maar, ik ben wel van mening dat geen enkele computer zonder ECC geheugen verkocht zou mogen worden. In dit tijdperk mag je verwachten dat computertechniek volwassen en extreem betrouwbaar is. Technisch gezien is dit prima mogelijk en de meerprijs is qua kostprijs insignificant.

Maar de praktijk is dat bedrijven bepalen welke prijs daarvoor wordt gevraagd, en door allerlei vormen van productsegregatie (CPUs, chipsets, moederborden) is de uiteindelijke meerprijs voor ECC best significant - voor de thuisgebruiker in elk geval.

Maar dat je die 150-200 euro extra "significant" vind is iets persoonlijks. Bovendien betaal je niet alleen voor ECC-geheugen, maar krijg je meer voor dat geld. Je krijgt in totaal:

1. Een Server bord in plaats van het goedkoopste van het goedkoopste consumenten spul (voor wat dat waard mag zijn, geen on-board audio flauwekul enzo)
2. Support voor ECC-geheugen
3. Meerdere on-board intel NICs
4. KVM over IP voor head-less remote management (mogelijk niet zo vaak gebruikt maar als je het nodig hebt erg fijn)

Als mensen aan punten 1,3, en 4 ook niet zoveel waarde hechten en bereid zijn om het risico te nemen, prima, bespaar je het geld en neem geen ECC-geheugen.

Maar je kunt al een CPU, Mobo + 8 GB RAM combo hebben met ECC-support voor rond de 320 euro. En voor minder zelfs met een microserver.

Veel mensen hier overwegen een ZFS systeem van een paar honderd euro. Dat valt niet te vergelijken met de situatie van zakelijke gebruikers waar alleen de SLA-agreements al de prijs extreem opvoeren en de hardwarekosten daarbij in het niet vallen. ECC is absoluut een no-brainer daarbij en logisch dat geen enkel zakelijk systeem zonder ECC verkocht wordt. En terecht.

Ik vind zelf dat je twee extremen tegen elkaar uitzet: de gewone privé persoon die echt gefocussed zijn op de euro's en ze zakelijke gebruikers met mission-critical applicaties.

Maar er is ook een grote groep mensen die toch anders kijken naar hun data. Die geven liever iets meer geld uit voor een bewezen oplossing en gedegen componenten om te voorkomen dat ze later alsnog een prijs betalen.

Ik denk dat de ECC-discussie ook in een iets groter kader past. Je bouwt een NAS waar je je data aan toe wilt gaan vertrouwen. Moet zo'n apparaat dan echt bestaan uit het goedkoopste van het goedkoopste?

It's a very sobering feeling to be up in space and realize that one's safety factor was determined by the lowest bidder on a government contract.

Veel DIY NAS bouwers twijfelen vaak nog tussen zelfbouw of een kant-en-klare NAS. Een Synology en QNAP zijn vaak best aan de prijs, zeker als je kijkt naar de zwakke CPUs die er in zitten, voor dat geld.

Met het budget voor een QNAP of Synology kun je ook zelf iets bouwen wat deze apparaten overstijg in termen van betrouwbaarheid en flexibiliteit.

Het mooiste is om een non-ecc en een ecc-based systeem qua kosten en specs naast elkaar te zetten en dan moge mensen zelf een keuze maken.

[dcm360]

justice strike schreef op donderdag 24 september 2015 @ 18:51:
[...]

dat is natuurlijk niet hoe een cluster werkt.

Hoe werkt het wel dan? Ik heb mijn cluster gevraagd om 1 byte in een bestand op te slaan, en om die byte op 2 of meer nodes op te slaan. Een van de nodes beweert (heeft op de storage staan) dat ik een 'a' heb opgeslagen, een andere beweert dat het een 'c' is. Ga ik nu willekeurig een 'a' of een 'c' terugkrijgen als ik mijn byte weer opvraag, of heeft het cluster door dat er iets niet in de haak is en kan mij de juiste waarde teruggeven (en de 'foute' node corrigeren)?

Q schreef op donderdag 24 september 2015 @ 19:52:
[...]
Maar je kunt al een CPU, Mobo + 8 GB RAM combo hebben met ECC-support voor rond de 320 euro. En voor minder zelfs met een microserver.

Met snel klikken in de pricewatch kom ik uit op 180 euro zelfs (Gebaseerd op een FX-4300, misschien is daar nog een goedkoper alternatief voor te vinden).

[ Voor 24% gewijzigd door dcm360 op 25-09-2015 00:47 ]

[begintmeta]

dcm360 schreef op vrijdag 25 september 2015 @ 00:34:
[...]

Hoe werkt het wel dan? Ik heb mijn cluster gevraagd om 1 byte in een bestand op te slaan, en om die byte op 2 of meer nodes op te slaan. Een van de nodes beweert (heeft op de storage staan) dat ik een 'a' heb opgeslagen, een andere beweert dat het een 'c' is. Ga ik nu willekeurig een 'a' of een 'c' terugkrijgen als ik mijn byte weer opvraag, of heeft het cluster door dat er iets niet in de haak is en kan mij de juiste waarde teruggeven (en de 'foute' node corrigeren)?

...

Melden dat iets niet in de haak is zou kunnen, en als je meer dan twee nodes hebt zou je ook kunnen zeggen dat bijvoorbeeld 2/3 of 4/5 voldoende is om een juiste waarde te geven, of te suggereren zoals al eerder is geopperd. Zo'n (triple) modular redundancy schijnt niet heel ongebruikelijk te zijn.

[justice strike]

dcm360 schreef op vrijdag 25 september 2015 @ 00:34:
[...]

Hoe werkt het wel dan? Ik heb mijn cluster gevraagd om 1 byte in een bestand op te slaan, en om die byte op 2 of meer nodes op te slaan. Een van de nodes beweert (heeft op de storage staan) dat ik een 'a' heb opgeslagen, een andere beweert dat het een 'c' is. Ga ik nu willekeurig een 'a' of een 'c' terugkrijgen als ik mijn byte weer opvraag, of heeft het cluster door dat er iets niet in de haak is en kan mij de juiste waarde teruggeven (en de 'foute' node corrigeren)?


[...]

Met snel klikken in de pricewatch kom ik uit op 180 euro zelfs (Gebaseerd op een FX-4300, misschien is daar nog een goedkoper alternatief voor te vinden).

Ten eerste is het heel onwaarschijnlijk dat je 1 byte opvraagd van een server.
Ten tweede zit er zoveel error correctie erom heen dat als je 1 byte opvraagd van 2 nodes je eigenlijk al weet welke byte fout is omdat de node zelf al weet dat het fout zit.
Ten derde als je met clusters werkt dan werk je bijna altijd met code die er voor zorgt dat de zaken in sync blijven en/of besluit wat te doen als dat niet zo is. (door bijvoorbeeld van de client side al checksumming mee te sturen.

Q schreef op donderdag 24 september 2015 @ 19:52:
[...]


En daar is precies waar het mis gaat. Sendfile is een performance maatregel, geen data security integriteit maatregel. Bovenstaande is precies het window waar het mis kan gaan en waarom ZFS niet tegen de gevolgen van rot werkgeheugen kan beschermen. Een extra copy zou het risico vergroten, maar dat maakt conceptueel niets uit.

Daarnaast speelt nog steeds het andere scenario waarbij ZFS natuurlijk RAM geheugen als kladpapier moet gebruiken voor al haar operaties en ook daar kan het mis gaan. Worst-case veries je je pool.
Dit is niet ZFS-specifiek en het risico is niet groot, maar het strookt niet met het beeld wat jij neer probeert te zetten dat ZFS een soort goddelijke oplossing is die alle risico's wegneemt en dat het ECC-geheugen effectief overbodig maakt.

Overigens om nog in te haken op het krijgen van data van het netwerk. Je hebt natuurlijk de checksumming van de TCP/IP stack die je kunt overnemen. Maw, je hebt dan volledige integriteit van het moment dat je de pakketten ontvangt totdat je je zfs checksumming hebt.

[ Voor 23% gewijzigd door justice strike op 25-09-2015 10:31 ]

[dcm360]

justice strike schreef op vrijdag 25 september 2015 @ 10:07:
[...]

Ten eerste is het heel onwaarschijnlijk dat je 1 byte opvraagd van een server.
Ten tweede zit er zoveel error correctie erom heen dat als je 1 byte opvraagd van 2 nodes je eigenlijk al weet welke byte fout is omdat de node zelf al weet dat het fout zit.
Ten derde als je met clusters werkt dan werk je bijna altijd met code die er voor zorgt dat de zaken in sync blijven en/of besluit wat te doen als dat niet zo is. (door bijvoorbeeld van de client side al checksumming mee te sturen.

De eerste: duh. Het is een voorbeeld.
De tweede en de derde: Ah, je laat de client dus extra data toevoegen. Bij het opvragen van de data, laat je de node dus controleren tegen een opgeslagen checksum of het nog correct is.

Kortom, in plaats van ecc heb je:
- een tweede systeem nodig
- een cluster file system
- meer storage om de overhead van het clustersysteem op kwijt te kunnen

En dan te bedenken dat ecc-geheugen slechts iets meer dan 10% duurder is dan geheugen zonder ecc. Ik zou voor ecc-geheugen gaan...

[justice strike]

dcm360 schreef op vrijdag 25 september 2015 @ 11:31:
[...]

De eerste: duh. Het is een voorbeeld.
De tweede en de derde: Ah, je laat de client dus extra data toevoegen. Bij het opvragen van de data, laat je de node dus controleren tegen een opgeslagen checksum of het nog correct is.

Kortom, in plaats van ecc heb je:
- een tweede systeem nodig
- een cluster file system
- meer storage om de overhead van het clustersysteem op kwijt te kunnen

En dan te bedenken dat ecc-geheugen slechts iets meer dan 10% duurder is dan geheugen zonder ecc. Ik zou voor ecc-geheugen gaan...

Ik geef een voorbeeld. Als je de client extra data laat toevoegen heb je helemaal geen ecc of extra geheugen nodig. De checksum zit dat bij de data. Overigens hebben meeste nfs protocollen checksumming want netwerken zijn inherent onbetrouwbaar. Het is echt niet moeilijk om fouten te voorkomen en ecc is echt niet de enige oplossing.

Zoek maar eens op wat beowulf clusters die op commodity hardware draaien. Ik ken legio universiteiten waar deze gebruikt worden voor zeer belangrijk onderzoek, die draaien niet altijd met ECC. Enfin, het is leuk, maar er zijn manieren om langs ECC heen te werken.

[dcm360]

Sorry, ik zie niet in wat de toevoeging is van jouw voorbeeld. Je krijgt sowieso niet de garantie dat de data correct op de storage terecht komt, want de bitflip kan prima optreden nadat de checksum is gecontroleerd. Bij het uitlezen van de data kan je nu achterhalen dat het fout is gegaan eerder, maar als je ecc-geheugen had gehad dan wist je dat al eerder, en had het nog correct op de storage geschreven kunnen worden.

Het verhaal over clusters op universiteiten is overigens ook wel leuk, maar sluit natuurlijk niet aan bij het neerzetten van een NAS thuis.

[justice strike]

dcm360 schreef op vrijdag 25 september 2015 @ 11:50:
Sorry, ik zie niet in wat de toevoeging is van jouw voorbeeld. Je krijgt sowieso niet de garantie dat de data correct op de storage terecht komt, want de bitflip kan prima optreden nadat de checksum is gecontroleerd. Bij het uitlezen van de data kan je nu achterhalen dat het fout is gegaan eerder, maar als je ecc-geheugen had gehad dan wist je dat al eerder, en had het nog correct op de storage geschreven kunnen worden.

Als je een bitflip hebt nadat de checksum is berekend dan maakt dat toch niet uit? dat is toch hetzelfde als wanneer er een bitflip op de schijf zelf voorkomt?

Het verhaal over clusters op universiteiten is overigens ook wel leuk, maar sluit natuurlijk niet aan bij het neerzetten van een NAS thuis.

ECC is ook iets voor enterprises meer dan thuis. Ik geef alleen een voorbeeld van een kritische omgeving waar men ook niet altijd voor ECC kiest.

Ik snap ansich wel wat je bedoelt, ik zeg alleen dat ECC een hardware oplossing is voor iets wat ook in de software opgelost kan worden (zonder softecc te gebruiken). Voor de thuisgebruiker is het ook niet echt de moeite om die 150 euro extra te betalen, dan zou ik liever een 2de systeem of een backup hd voor kopen, dat voegt dan meer waarde toe in een thuis situatie.

[FireDrunk]

softecc is een drog reden, want je kan nooit garanderen dat voordat het geheugen naar de andere applicatie getransporteerd wordt, er niet een geheugen bitflip is geweest..

Denk aan het volgende:

1) Er komt data binnen in het geheugen
2) Er wordt een checksum berekend
3) De checksum wordt naast de data gezet
4) Een applicatie gaat met de data aan de slag.
5) Tussen verschillende functies door wordt er steeds geverifieerd of de data nog aan de checksum voldoet.
6) Voordat de data getransporteerd wordt naar bijvoorbeeld een netwerkkaart word nog 1 keer de checksum gevalideerd.
7) Op *dat* moment treed er een bitflip op.
8 ) De CPU leest daarna het geheugen uit, wat hij direct in het geheugen van de Netwerkkaart zet...

Dan kan je een miljoen checksums hebben, maar je gaat die bitflip niet detecteren, *tenzij* de driver van de netwerkkaart ook een software matige checksum implementatie heeft.

Dat is juist het grote nadeel van softwaremataige oplossingen. Omdat je niet de hele keten van garanderen, *moet* je het wel in hardware oplossen.

Dat wil niet zeggen dat Software matige checksumming überhaupt slecht is, het *helpt* maar is geen *oplossing*.

Net als dat ECC dat persé perfect hoeft te zijn, omdat je altijd tegen hardware aan kan praten die zelf geen ECC ondersteuning heeft (denk aan: Netwerkkaarten, Fiber Channel adapters, AHCI/SATA Controllers, USB, InfiniBand)

[ Voor 13% gewijzigd door FireDrunk op 25-09-2015 12:34 ]

[Ultraman]

Even los van de direct bovenstaande reacties, mijn recentste ervaring:

Anderhalve maand geleden gaf mijn server met FreeBSD ineens een aantal meldingen in het log. Afkomstig van de kernel een aantal mce meldingen over het geheugen. Die meldingen door mcelog gegooid om te decoderen en daar kwam o.a. het volgende uit:

code:

HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 0 4 northbridge 
ADDR 2ea191870 
  Northbridge RAM Chipkill ECC error
  Chipkill ECC syndrome = 92a4
       bit40 = error found by scrub
       bit46 = corrected ecc error

Hela een ECC error. Blijkt de ECC in dat oudere Athlon X2 AM3 bakkie dus toch prima te werken!

Die machine is mijn mail server (IMAP), web server, Owncloud (contacts, calendar en wat files) en file server (veel media en backups van andere machines). Al met al voor toch een tamelijk mission critical bakkie, want het is best vervelend als hij er plots mee zou stoppen. Daarom hangt dat apparaat aan een UPS, doet het RAID en zijn er backups.

ECC redde mijn bacon nu, want er was duidelijk een chip bit errors aan het maken maar tijd om daar op dat moment naar te kijken was er niet. Heeft zo nog een week doorgedraaid voordat ik tests kon gaan doen met Memtest86 om te kijken wat er mis was. ECC tijdelijk uit gezet en toen kwamen meerdere rode meldingen in Memtest86 naar voren rond een bepaald geheugengebied. Daardoor wist ik welk setje van 2 repen naar de knoppen was en die is inmiddels teruggestuurd voor RMA.

Die machine heeft door kunnen draaien omdat ik destijds een enkele tientjes heb geïnvesteerd in ECC. Voor het AM2/AM3 platform was het destijds zeer betaalbaar en gemakkelijk omdat Asus borden het ondersteunde en de AMD processoren ook. Als het nu 100 euro meer zou kosten zou ik het doen.

De afweging is hoe belangrijk de machine voor je is. Maar als je agenda, contacts en email er op draait dan moet het spul gewoon werken en is het dat geld dubbel en dwars waard. ECC heeft single bit errors kunnen afvangen waardoor er niets in de soep is gelopen en de machine door heeft kunnen draaien tot ik tijd had om er naar te kijken. In plaats een gecrashde machine waar ik dan per direct tijd aan moet gaan besteden en niet direct had geweten wat er mis was geweest. Het had zonder ECC veel vervelender kunnen zijn.

De afweging voor mij: Staat het 24/7 aan en is het (semi-)belangrijk: ECC ondersteuning er in.

[Q]

100% eens met het verhaal van Firedrunk hierboven.

justice strike schreef op vrijdag 25 september 2015 @ 11:56:

ECC is ook iets voor enterprises meer dan thuis.

Gelden er dan andere natuurwetten in enterprises dan thuis?

Het enige verschil tussen thuis en een enterprise omgeving is de schaal. Dus de kans dat je getroffen wordt door een risico'. Maar je bent niet immuum voor een risico.

Wat ik meer als echte enterprise features beschouw die we thuis gewoon nooit nodig hebben zijn zaken als dubbele voedingen, redundant RAM geheugen, hot-swap CPUs, etc.

Het is jammer dat een partij als Intel - waar CiPHER terecht over klaagt - ECC-support niet ondersteund in consumenten CPU's en chipsets, wat de kosten om van ECC-geheugen onnodig opdrijft.

Maar so be it, dat is een gegeven waar we niets aan kunnen doen.

Voor de thuisgebruiker is het ook niet echt de moeite om die 150 euro extra te betalen, dan zou ik liever een 2de systeem of een backup hd voor kopen, dat voegt dan meer waarde toe in een thuis situatie.

Ik ben het hier niet mee eens.

- Een 2e systeem of een backup HD helpt je niet om tegen de risico's die ECC-geheugen afdekt te beschermen.
- Voor 150 euro extra zet je echt geen praktisch/bruikbaar 2e systeem neer.
- Een 2e systeem kost ook weer zijn eigen stroom of je moet met WoL werken (geknutsel).
- hoeveel DIY-Nas gebruikers die hier voorbij komen zijn bereid om 2 systemen neer te zetten?

[Q]

Ultraman schreef op vrijdag 25 september 2015 @ 13:05:
Even los van de direct bovenstaande reacties, mijn recentste ervaring:
ECC heeft single bit errors kunnen afvangen waardoor er niets in de soep is gelopen en de machine door heeft kunnen draaien tot ik tijd had om er naar te kijken.

Interessante ervaring.

Misschien ter aanvulling om iets over ECC te verduidelijken voor anderen: wat jij hebt gedaan is 100% veilig. Je kunt inderdaad gewoon doordraaien totdat je in de gelegenheid bent om actie te ondernemen.

En je weet ook dat je machine altijd beschermd is, want bij een double bitflip zal je systeem meteen een halt krijgen zodat de geheugen corruptie geen impact kan hebben op lopende processen en data on-disk.

Liever een halt dan dat random bitjes worden geflipt met alle gevolgen van dien.

[justice strike]

FireDrunk schreef op vrijdag 25 september 2015 @ 12:32:
softecc is een drog reden, want je kan nooit garanderen dat voordat het geheugen naar de andere applicatie getransporteerd wordt, er niet een geheugen bitflip is geweest..

Denk aan het volgende:

1) Er komt data binnen in het geheugen
2) Er wordt een checksum berekend
3) De checksum wordt naast de data gezet
4) Een applicatie gaat met de data aan de slag.
5) Tussen verschillende functies door wordt er steeds geverifieerd of de data nog aan de checksum voldoet.
6) Voordat de data getransporteerd wordt naar bijvoorbeeld een netwerkkaart word nog 1 keer de checksum gevalideerd.
7) Op *dat* moment treed er een bitflip op.
8 ) De CPU leest daarna het geheugen uit, wat hij direct in het geheugen van de Netwerkkaart zet...

Dan kan je een miljoen checksums hebben, maar je gaat die bitflip niet detecteren, *tenzij* de driver van de netwerkkaart ook een software matige checksum implementatie heeft.

Dat is juist het grote nadeel van softwaremataige oplossingen. Omdat je niet de hele keten van garanderen, *moet* je het wel in hardware oplossen.

Dat wil niet zeggen dat Software matige checksumming überhaupt slecht is, het *helpt* maar is geen *oplossing*.

Net als dat ECC dat persé perfect hoeft te zijn, omdat je altijd tegen hardware aan kan praten die zelf geen ECC ondersteuning heeft (denk aan: Netwerkkaarten, Fiber Channel adapters, AHCI/SATA Controllers, USB, InfiniBand)

Je TCP/IP stack zou daar al tegen bestand moeten zijn.

de volgorde is:
1) Er komt data binnen in het geheugen
2) Er wordt een checksum berekend
3) De checksum wordt naast de data gezet
4) Een applicatie gaat met de data aan de slag.
5) Tussen verschillende functies door wordt er steeds geverifieerd of de data nog aan de checksum voldoet.
6) Voordat de data getransporteerd wordt naar bijvoorbeeld een netwerkkaart word nog 1 keer de checksum gecalculeerd en doorgestuurd naar de netwerk kaart.
7) Op *dat* moment treed er een bitflip op.
8 ) De CPU leest daarna het geheugen uit, wat hij direct in het geheugen van de Netwerkkaart zet...
9) omdat TCP/IP een checksum heeft kan er worden gedectecteerd en in sommige gevallen gecorrigeerd.

Dit ligt natuurlijk ook aan de implementatie van je stack. Maar ik kan je vertellen dat ons huidige netwerk bijna niet werkt zonder checksums. Je zou haast niet kunnen detecteren wanneer een packet onvolledig is.

Ik heb toentertijd zelf een tcp/ip stack moeten schrijven (van scratch) dus ik ben zeer op de hoogte van hoe zo'n stack in elkaar zit. Overigens heb ik ook een memory pager moeten schrijven en je komt er achter dat er best veel te doen is om dit soort fouten tegen te gaan.


Mijn punt is hier ook niet dat ECC geen functie heeft, maar dat ECC veel minder fouten afvangt dan een backup op een Externe HD of een tweede offsite systeem (of backup solution) kan afvangen.

ECC beschermt je bijvoorbeeld niet voor het afbranden van je huis, diefstal of user error. De kans dat dat gebeurt is vele malen groter dan de schade die door een bitflip kan voorkomen.

[ Voor 8% gewijzigd door justice strike op 25-09-2015 14:30 ]

[FireDrunk]

Je gaat de mist in tussen stap 8 en 9.
De netwerkkaart berekend namelijk zijn eigen checksum over de data, en gebruikt niet dezelfde checksum als je softwarematige oplossing.

Er wordt daarna dus gewerkt met een checksum die berekend is over de data inclusief bitflip.

Je gaat hem dus niet meer zien.

[justice strike]

FireDrunk schreef op vrijdag 25 september 2015 @ 14:48:
Je gaat de mist in tussen stap 8 en 9.
De netwerkkaart berekend namelijk zijn eigen checksum over de data, en gebruikt niet dezelfde checksum als je softwarematige oplossing.

Er wordt daarna dus gewerkt met een checksum die berekend is over de data inclusief bitflip.

Je gaat hem dus niet meer zien.

Als je een software stack hebt, berekend je netwerkkaart niets. Daarbij zit er volgens mij ook checksumming in het nfs en/of smb protocol wat verder gaat dan de tcp/ip stack.

Enfin, ik hoor graag van een praktijk voorbeeld waarbij dit gebeurd is door een bitflip in het geheugen. Ik heb het nog nooit voor zien komen.

[ Voor 20% gewijzigd door justice strike op 25-09-2015 15:01 ]

[FireDrunk]

Nee hoor, de moderne Intel NIC's hebben ECC in de chip zitten (vanaf de x-* series volgens mij.)
En na je edit:

Al zit er een checksum mechanisime in NFS, dat helpt niets. Je data moet op enig moment getransporteert worden tussen Applicatie en NFS, juist op dat moment is je data kwetsbaar, omdat het geen atomaire operatie is met ECC. (het zijn 2 operaties, 1 * ECC checksum checken, en daarna data kopieren.).

Bij hardware ECC is een kopieslag en de verifcatieslag, 1 atomaire operatie.

[ Voor 67% gewijzigd door FireDrunk op 25-09-2015 15:02 ]

[justice strike]

FireDrunk schreef op vrijdag 25 september 2015 @ 15:01:
Nee hoor, de moderne Intel NIC's hebben ECC in de chip zitten (vanaf de x-* series volgens mij.)

waar reageer je nu op?

En na je edit:
Al zit er een checksum mechanisime in NFS, dat helpt niets. Je data moet op enig moment getransporteert worden tussen Applicatie en NFS, juist op dat moment is je data kwetsbaar, omdat het geen atomaire operatie is met ECC. (het zijn 2 operaties, 1 * ECC checksum checken, en daarna data kopieren.).

Bij hardware ECC is een kopieslag en de verifcatieslag, 1 atomaire operatie.

ik denk dat je mijn punt niet wil zien. Enfin, zoals ik al zei, laat me maar een voorbeeld zien waarbij er een bitflip in die situatie is voorgekomen. Ik heb dat nog niet meegemaakt.

[Q]

justice strike schreef op vrijdag 25 september 2015 @ 14:20:
ECC beschermt je bijvoorbeeld niet voor het afbranden van je huis, diefstal of user error. De kans dat dat gebeurt is vele malen groter dan de schade die door een bitflip kan voorkomen.

Maar dat maakt ECC-geheugen nog niet minder waardevol.

Het draait allemaal om het risico dat je data verloren gaat. Er zijn vele scenarios hoe je data verloren kan gaan:

1. user error
2. falende disks
3. falende voeding
4. rot geheugen
5. brand
6. diefstal
7. etc.

Ieder risico heeft zijn eigen mitigerende factor.

Je wapent je tegen brand met off-site backups
Je wapent je tegen data corruptie door een brakke storage laag met ZFS
Je wapent je tegen disk uitvall door RAID
Je wapent je tegen rot geheugen door ECC toe te passen

Iedere mitigerende factor brengt 'kosten' met zich mee. Sommige kosten zijn geld. Andere kosten is dat je misschien moet verdiepen in non-Windows oplossingen waar je niet in thuis bent.

Jouw punt is dat je misschien beter die centen die je in ECC geheugen zou stoppen kunt besteden aan andere zaken waarvan het risico veel groter is. Dus je neemt het risico wat ECC afdekt en met het geld wat vrij komt kun je andere grotere risico's afdekken.

Als je budget zo laag is dat je moet kiezen tussen ofwel off-site backup of ECC-geheugen, dan ben ik de eerste om te roepen: kies voor een off-site backup!

Maar als je het geld hebt dan kun je beiden doen. Geheugen rot komt weinig voor maar het komt wel voor, zoals hierboven nog anekdotisch is geillustreerd.

Laten we nu eens specifiek naar de doelgroep kijken.

Voor heel veel DIY-NAS bouwers geldt dat een 100% off-site backup niet realistisch en niet betaalbaar is. Er is meestal slechts een sub-set van kritische data, zoals foto's en documenten. Dat is meestal relatief weinig data, 1 TB is vaak al veel.

Die subset van data kan worden afgedekt met cloud backup.

Laten we nou goed kijken naar het publiek voor DIY-NAS bouwers: willen die mensen twee systemen neer gaan zetten? Ik denk het niet, daar zitten mensen niet op te wachten en dat lukt ook nooit voor 150 euro.

De meeste DIY-NAS bouwers roepen eigenlijk allemaal heel stoer: als ik mijn media verlies dan download ik het wel opnieuw. Maar als ik naar mijzelf kijk dan zou ik het super jammer vinden als ik alles kwijt raak. Want het verzamelen heeft enorm veel tijd gekost.

Maar een 1-op-1 backup van de data is niet betaalbaar / niet realistisch. Dus wat doe je dan?

Binnen die context kun je dan er beter voor zorgen - in mijn ogen - dat je NAS zo robuust mogelijk is opgezet en dat je dus met name investeert in goede 'server-grade' componenten en ook ECC-geheugen, om het risico te minimaliseren dat die enkele server naar de hemel gaat. De keuze voor ZFS hoort daar ook bij.

Natuurlijk kun je cynische opmerkingen plaatsen over de werkelijke kwaliteit van 'server-grade' componenten, maar alle beetjes helpen binnen deze context.

Diefstal, blikseminslag en brand kun je hier niet mee mitigeren, maar dat maakt ECC-geheugen dus niet minder waardevol.

Het geld dat je uitspaart door non-ecc geheugen toe te passen geeft je in de meeste gevallen onvoldoende middelen om genoemde risico's te addreseren voor alle data op de server.

In deze context is er alles aan gelegen dat die enkele server zo robuust mogelijk is. En juist in deze context is de toepassing van ECC-geheugen in mijn ogen extra waardevol.

[FireDrunk]

justice strike schreef op vrijdag 25 september 2015 @ 15:08:
[...]

waar reageer je nu op?

Sorry, ik denk dat ik te snel over je berichtje heen heb gelezen. Ik ga er even vanuit dat een groot deel van het TCP/IP stack geoffload wordt naar de driver van je netwerkkaart (welke zelf weer kan kiezen of iets in hardware gedaan wordt).

Daar zit in moderne netwerkkaarten lekker ECC (tijdens die offloading dus al).

[...]

ik denk dat je mijn punt niet wil zien. Enfin, zoals ik al zei, laat me maar een voorbeeld zien waarbij er een bitflip in die situatie is voorgekomen. Ik heb dat nog niet meegemaakt.

Ik wil juist heel graag begrijpen waar het over gaat, maar ik zie nog niet in hoe een checksum in een TCP stack het grote probleem oplost.

En over je laatste zin:
Die lezen we hier wel vaker: Dat is hetzelfde als zeggen dat ZFS niet nodig is omdat je zelf nog nooit een kapotte RAID array hebt gehad door een bitflip op de disk.

Ik wil je niet aanvallen, maar er is een verschil tussen een theoretische kans beredeneren en zeggen dat het onrealistisch is dat het voorkomt: "Omdat je het nog nooit gezien hebt".

De kern van het probleem is, dat tussen verschillende software stacks er geen transport garantie is door middel van checksums. Hoe veel softwarematige checksums je ook toevoegt, er is altijd (hoewel kleine) kans dat er een bitflip optreed tijdens transport *binnen* hetzelfde geheugen.

[ Voor 9% gewijzigd door FireDrunk op 25-09-2015 15:46 ]

[riwi]

Ik snap het argument van de 150 euro voor een extra server niet. Voor 150 euro heb je net 1 harddisk.

Mijn 2de nas server heeft nu ECC (de 1ste niet helaas).
270 moederbord, 130 processor, 300 ecc geheugen, 100 voeding, 100 kast, 70 voor 4-in-3 module, 80 sata/etc kabels, 40 cpu fan en 1500 voor 10 harde schijven.
Als je dat vergelijkt met een non-ecc setup dan scheelt dat misschien 100 euro kwa moederbord en 100 euro kwa geheugen prijs. dwz 2500 vs 2300 ongeveer. En als je dat dan toch uitgeeft dan mag dat ECC er wel bij.

[justice strike]

FireDrunk schreef op vrijdag 25 september 2015 @ 15:44:

De kern van het probleem is, dat tussen verschillende software stacks er geen transport garantie is door middel van checksums. Hoe veel softwarematige checksums je ook toevoegt, er is altijd (hoewel kleine) kans dat er een bitflip optreed tijdens transport *binnen* hetzelfde geheugen.

laten we even het meest extreme geval nemen dat je via het netwerk (nfs) een file met checksum krijgt. Dit wordt dan in het geheugen geplaatst (beide de file en de checksum) en dan weggeschreven (beide de file en de checksum). Ik zie in dit geval niet hoe non-ecc daar een probleem introduceert.

[jacovn]

Ook maar in de pc een mainbord met ecc gezet. Geheugen inderdaad duurder, maar 2e hands mainbord met een e3-1220 erbij voor 175€ viel mee.

[dcm360]

justice strike schreef op vrijdag 25 september 2015 @ 17:34:
[...]


laten we even het meest extreme geval nemen dat je via het netwerk (nfs) een file met checksum krijgt. Dit wordt dan in het geheugen geplaatst (beide de file en de checksum) en dan weggeschreven (beide de file en de checksum). Ik zie in dit geval niet hoe non-ecc daar een probleem introduceert.

De meegestuurde checksum wordt niet weggeschreven, dat is het hele probleem. NFS zet het in het geheugen, valideert de checksum en is klaar met zijn taak. Het filesystem leest het geheugen, maakt een checksum en schrijft dat weg. Je hebt geen garantie dat het filesystem hetzelfde wegschijft als wat aangeleverd is door NFS.

[FireDrunk]

Exact!

[justice strike]

dcm360 schreef op vrijdag 25 september 2015 @ 18:03:
[...]

De meegestuurde checksum wordt niet weggeschreven, dat is het hele probleem. NFS zet het in het geheugen, valideert de checksum en is klaar met zijn taak. Het filesystem leest het geheugen, maakt een checksum en schrijft dat weg. Je hebt geen garantie dat het filesystem hetzelfde wegschijft als wat aangeleverd is door NFS.

ik zeg niet dat het NFS een checksum maakt, ik zeg het meest extreme geval je krijgt een file met checksum (zegmaar par). Ik zie niet in hoe non-ecc geheugen hier een fout in kan maken.

[dcm360]

Nou, precies zoals ik zeg!?

Je schrijft het par-bestand weg, en dat gaat om een of andere reden fout. Pas op het moment dat je het bestand weer terugvraagt, kom je er achter dat er ergens iets fout gegaan is (en kan je het met een par hopelijk corrigeren). Neemt niet weg dat je de gehele tijd tussen het opslaan en weer opvragen een bestand met foutieve data op de opslagmedia had staan, terwijl dat in sommige gevallen door gebruik van ecc-geheugen voorkomen had kunnen worden. Daarbij heb ik weinig zin om al mijn bestanden te gaan parren.

[Ultraman]

Q schreef op vrijdag 25 september 2015 @ 13:16:
[...]


Interessante ervaring.

Misschien ter aanvulling om iets over ECC te verduidelijken voor anderen: wat jij hebt gedaan is 100% veilig. Je kunt inderdaad gewoon doordraaien totdat je in de gelegenheid bent om actie te ondernemen.

En je weet ook dat je machine altijd beschermd is, want bij een double bitflip zal je systeem meteen een halt krijgen zodat de geheugen corruptie geen impact kan hebben op lopende processen en data on-disk.

Liever een halt dan dat random bitjes worden geflipt met alle gevolgen van dien.

Wat kiezen voor ECC geheugen voor thuisgebruik zo'n discussiepunt maakt zijn meerprijs vs nut.
Voor mij was met het AM3 AMD systeem de meerprijs twee tientjes op 2 x 4GB repen, peanuts.

En als ik ga nadenken is dit voor mij het allereerste setje geheugen in thuisgebruik welke ik RMA heb gestuurd... in zeker 10 jaar.
Heb wel eens een slecht reepje RAM gehad, maar dat was meestal een oudere reep die al mishandeld was door zonder ESD bescherming te werken of defect was geraakt op zo'n manier dat hij in zijn geheel niet meer herkend werd door het moederbord.
Het was dan ook een vrij unieke ervaring om ECC daadwerkelijk "in actie" te zien en er profijt van te hebben gehad.

[Q]

justice strike schreef op vrijdag 25 september 2015 @ 14:20:

6) Voordat de data getransporteerd wordt naar bijvoorbeeld een netwerkkaart word nog 1 keer de checksum gecalculeerd en doorgestuurd naar de netwerk kaart.
7) Op *dat* moment treed er een bitflip op.
8 ) De CPU leest daarna het geheugen uit, wat hij direct in het geheugen van de Netwerkkaart zet...
9) omdat TCP/IP een checksum heeft kan er worden gedectecteerd en in sommige gevallen gecorrigeerd.

Dit ligt natuurlijk ook aan de implementatie van je stack. Maar ik kan je vertellen dat ons huidige netwerk bijna niet werkt zonder checksums. Je zou haast niet kunnen detecteren wanneer een packet onvolledig is.

Ik heb toentertijd zelf een tcp/ip stack moeten schrijven (van scratch) dus ik ben zeer op de hoogte van hoe zo'n stack in elkaar zit. Overigens heb ik ook een memory pager moeten schrijven en je komt er achter dat er best veel te doen is om dit soort fouten tegen te gaan.

Ik heb er even over na zitten denken, want in eerste instantie dacht ik dat je hierboven inderdaad end-to-end data integriteit kan bewaren, maar nu besef ik dat dit niet zo is.

Als je de RAM hardware niet kunt vertrouwen, ben je nooit zeker van data integriteit.

Een checksum over data is altijd een snapshot in de tijd. Het is een moment opname. Op dat moment is de data intact, maar met het verstrijken van de milliseconde ben je niet zeker dat dit nog steeds zo is.

Je hebt altijd een proces van:

1. je hebt data & een checksum
2. je berekent een checksum over de data
3. je vergelijkt beide checksums
4. De checksums zijn gelijk
5. hoe weet je dat de data op dat moment nog steeds dezelfde is als de data waar je zojuist het checksum over hebt berekend?

Het is misschien paranoia, maar dat is dus wel het principe.

-----------

Dit artikel, wat ik wel eens eerder heb gedropt, laat zien waarom ZFS voor schijven extra belangrijk is voor DIY NAS bouwers.

http://download.intel.com...op_class_hard_drives_.pdf

Harde schijven hebben wat cache geheugen, vaak iets tussen de 32 MB tot 128 MB.
Alleen enterprise schijven passen hier ECC-geheugen toe. Dus desktop class harde schijven doen het met non-ECC geheugen.

Juist als je consumenten schijven gaat gebruiken voor je NAS is ZFS extra relevant. Beetje off-topic, maar wel leuk puntje.

[begintmeta]

Data checksumming wordt natuurlijk niet alleen door ZFS gedaan

[Q]

Als je doelt op het feit dat BTRFS ook een kandidaat is true maar dat file system is nog niet af.

[begintmeta]

Behalve wat filesystems (ZFS, NILFS, HAMMER, ReFS, BTRFS en wellicht nog wel wat andere, waarbij sommigen nog niet af en sommigen misschien discutabel af, zfs is natuurlijk wel de vaandeldrager) is er ook andere software die data checksumt.

Ik ben ook wel nieuwsgierig naar hoe men bijvoorbeeld bij coyotos of phantom data veilig denkt te houden.

[ Voor 22% gewijzigd door begintmeta op 26-09-2015 00:11 ]

[Q]

Ultraman schreef op vrijdag 25 september 2015 @ 20:25:
[...]



Wat kiezen voor ECC geheugen voor thuisgebruik zo'n discussiepunt maakt zijn meerprijs vs nut.
Voor mij was met het AM3 AMD systeem de meerprijs twee tientjes op 2 x 4GB repen, peanuts.

Ik heb nog eens gekeken of AMD een mogelijkheid biedt om toch ECC-geheugen toe te kunnen passen voor een lagere meer-prijs maar anno nu zie ik alleen maar zeer onzuinige processors. Los van de prestaties alleen al om die reden is AMD nu niet echt een optie meer.

Voor wie ECC-geheugen wil, zal daar voor moeten betalen.

[dcm360]

Het voorbeeld van 180 euro dat ik gaf (met FX-4300) is er inderdaad niet een die je daadwerkelijk zou willen bouwen. Wat betreft energieverbruik zijn de iets duurdere Opterons interessanter, maar ook die zijn alweer uit 2012. Het valt te hopen dat AMD komend jaar na 4 jaar met wat fatsoenlijks weet te komen (uberhaupt al, niet alleen vanwege ecc).

[begintmeta]

En dat ze dan zoals het hoort ECC-ondersteuning aan blijven bieden. Een paar jaar geleden was voor sommige doeleinden nog wel een AMD (Piledriver) te verantwoorden (ik heb er toen een genomen), maar tegenwoordig is dat IMHO een stuk lastiger geworden, zeker als het om doeleinden gaat waar ECC echt van belang zou zijn.