ECC geheugen voor zelfbouw ZFS NAS?

[Ultraman]

Q schreef op zaterdag 26 september 2015 @ 22:19:
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.

De mogelijkheden bij AMD met ECC ondersteuning is wat lastiger geworden, maar zeker niet onmogelijk voor een betaalbare prijs. En onzuinige processoren? Valt toch reuze mee? TDP Intel vs AMD is niet vergelijkbaar en meeste thuisservers zijn toch voornamelijk idle (mijne is doorgaans rustig qua CPU iig). Voor zover mij bekend ben je met idle verbruik meer afhankelijk van de efficientie van voeding bij lage vermogensafname.

Socket AM1 ondersteunt met een paar specifieke combinaties (Asus mobo waarbij ze support aangeven) prima ECC. Ik meen dat de pricewatch: AMD Athlon 5350 Boxed samen met pricewatch: Asus AM1M-A een ECC ondersteunende combinatie is, voor een toch zeer betaalbare prijs en volgens mij niet zeer onzuinig. Als ik _nu_ mijn thuisserver zou moeten vervangen zou ik zoiets gaan halen denk ik, kost echt helemaal niks.

Los van de prestaties alleen al om die reden is AMD nu niet echt een optie meer.

Prestaties van AMD processoren zijn prima voor home server taken. Vrijwel elke moderne CPU is overkill voor een willekeurige thuisbox.

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

Niet per se imo. Hangt nogal van je eisenpakket af.

[ Voor 9% gewijzigd door Ultraman op 27-09-2015 16:13 ]

[Q]

@Ultraman: je hebt gelijk. Ik heb niet goed gekeken. Hier een kaal bordje met geheugen en CPU wat 14 watt doet. Lijkt mij prima.

http://www.legitreviews.c...-platform-review_139224/6

Hier vergelijken ze een AMD Athlon 5350 met een Intel J1900:

http://www.tomshardware.c...atform-review,3801-9.html

31 watt om 27.5 Watt. Scheelt 3.5 watt dus.

Een J1900 is echter trager 811 om 527 single threaded passmark.

Dus helemaal niet zo'n gekke processor.

#	Product	Prijs	Subtotaal
1	AMD Athlon 5350 Boxed	€ 47,-	€ 47,-
1	Asus AM1M-A	€ 34,50	€ 34,50
1	Kingston ValueRAM KVR16E11/8	€ 59,-	€ 59,-
1	LSI SAS3081E-R-SGL	€ 90,75	€ 90,75
Bekijk collectie Importeer producten		Totaal	€ 231,25

[player-x]

Q schreef op zaterdag 26 september 2015 @ 22:19:
Voor wie ECC-geheugen wil, zal daar voor moeten betalen.

Voor 100 + 20 euro extra heb je een mobo met ECC en ECC geheugen.

Zijn er extra kosten, ja, zijn ze extreem hoog, niet echt als je een Celeron systeem bouwt met ECC.

Maar non-ECC ZFS is vele malen veiliger voor data integriteit, dan welke ext4 of NTSF file systeem van een NAS of server met ECC, daar ZFS zich zelf controleert.

Denk dat deze auto analogie nog steeds redelijk op gaat voor thuis gebruikers.

FAT - een jaren 60 auto zonder gordels.
NTFS & ext4 - een jaren 70 auto met een heup gordeltje
ZFS - een moderne auto met ABS, 3 punts gordel en airbags.
ZFS + ECC - voegt daar nog eens zij impact airbags aan toe.

Ik denk dat het een redelijke analogie is, maar waar het op neer komt is, dat als je als thuis gebruiker op een budget kan kiezen tussen NTFS/ext4 en ZFS, ZFS de voorkeur heeft, zelfs zonder ECC.

Zelf heb ik tegenwoordig ECC in mijn drie servers, daar de meer kosten, zo gering waren ten opzichte van de risico's, dat ik er gewoon voor gegaan ben, maar niet iedereen zal het geld er voor over hebben, of een +50TB hebben, en veel mensen hergebruiken een oud systeem, en gebruiken die om daar hun server van te bouwen.

• Vind ik het voldoende om een airbag te hebben omdat je auto alleen maar woon/werk verkeer gebruik, (lees gebruik geen ECC).
• Of betaal ik meer voor het optie pakket met extra airbags, omdat je +50.000km/jaar rijd, en daarom een verhoogd risico loop, of heb geld over en kan het me veroorloven, (lees gebruik wel ECC)

[Q]

@Player-x: die prijzen zijn in de pricewatch veel hoger dan wat je noemt. Bovendien kies je 4 GB ipv 8 GB geheugen.

Ik denk zelf dat je beter af bent met een machine op basis van ECC-geheugen en een legacy file system dan een machine zonder ECC-geheugen en ZFS.

ZFS draaien zonder ECC geheugen is wat mij betreft data integriteit 'theater'.

Als je geen ECC-geheugen toepast dan vind je data integriteit gewoon niet zo belangrijk en dan maakt het ook niet zoveel uit of je ZFS draait of niet. Als je meent dat je het wel zonder ECC geheugen af kunt, dan kun je ook prima zonder ZFS.

Prima als je toch voor ZFS kiest, maar het zou onzin zijn als je dat doet om de reden 'het is veiliger'. Want dat is niet zo relevant meer. Relevanter zou zijn als je gewoon het file system beheer van ZFS prettig vind en graag van compressie gebruik wilt maken. Vind ik zelf dan in die context betere redenen. Maar ga je voor NTFS/XFS, ook goed.

Ik vind het zelf gewoon vreemd dat sommige mensen hun data wil toevertrouwen aan het goedkoopste van het goedkoopste qua hardware, om zich dan druk te maken over ZFS. Waar liggen je prioriteiten nu?

[FireDrunk]

@Q, Dat AM1 bordje doet helemaal geen ECC volgens de site van ASUS?

@Q-hierboven.

Daar ben ik het dus niet helemaal mee eens. Ik kan het gewoon niet met je eens zijn dat omdat er een kans is van 1 promille dat ZFS op non-ECC hardware iets stuk draait, je het hele filesystem de rug toe wijst (op non-ECC hardware), en dan meteen roept dat je "net" zo goed af bent met NTFS of Ext4.

Ik kan die beredenering niet volgen...

Dus omdat een Tesla een computer bevat die fouten kan maken, ben je veiliger af in een Dafje uit 1970?
Geef mij dan nog altijd maar een Golf VII uit 2015

Ik snap eerlijk waar niet (en dat is echt niet aanvallend bedoelt) waarom je de kans op een fout ziet als de afschrijving van een heel product...

_{nogmaals, ECC is gewoon altijd beter, dat stel ik niet ter discussie}

[ Voor 3% gewijzigd door FireDrunk op 12-12-2015 11:12 ]

[player-x]

Q schreef op zaterdag 12 december 2015 @ 03:30:
@Player-x: die prijzen zijn in de pricewatch veel hoger dan wat je noemt. Bovendien kies je 4 GB ipv 8 GB geheugen.

Ongeveer 10 euro extra per reepje x2 is bij mijn weten nog altijd 20 euro, en 2x 4GB is als ik het goed heb nog steeds 8GB, meer dan voldoende voor normaal thuis gebruik in een server met ZFS.

En het bord dat ik linkte is gewoon 150 euro, dat is 100 euro meer dan een vergelijkbaat budget bordje.

Ik denk zelf dat je beter af bent met een machine op basis van ECC-geheugen en een legacy file system dan een machine zonder ECC-geheugen en ZFS.

Ik heb nooit goed begrepen waar je die echt wijsheid vandaan haalt, want meestal gebruik je deze quote om jouw gelijk te bewijzen, maar die lees ik toch heel anders dan jij.

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.

Wat de quote zegt is dat ZFS geen extra bescherming geeft tegen bitflips, dan andere file systemen, maar bitflips is maar een heel klein risico van alle gevaren van de data integriteit van je file systeem, en dat terwijl er voor file systeem, vooral het gevaar van bitflips veel groter is op de HDDs die men gebruikt.

Ik vind het zelf gewoon vreemd dat sommige mensen hun data wil toevertrouwen aan het goedkoopste van het goedkoopste qua hardware, om zich dan druk te maken over ZFS. Waar liggen je prioriteiten nu?

Al jaren is het bekend dat bij grotere disk, R5 gewoon heel onbetrouwbaar wordt, en dat probleem kan je prima ondervangen met ZFS.

Ik weet dat je gelooft in wat je zegt, maar er zijn nergens echte tests gedaan om te onderzoeken wat het risico is van het wel of niet gebruiken van ECC, dus ik, samen met andere mensen die zeggen dat het een risico is waar de kosten/baten afweging in het voordeel van ZFS ligt, te opzichte van vorige generatie file systemen zo als NTFS, is iets dat we niet met bewijzen kunnen hard maken, maar dat we tot die conclusie zijn gekomen door in onze mening gewoon gezond verstand te gebruiken.

Maar voor jouw stelling zijn er ook nergens harde bewijzen, en iig imho is het meer FUD dan iets dat daadwerkelijk bewezen kan worden, daar harde data gewoon ontbreekt.

En voor bedrijven is het een non issue, want die willen gewoon server grade hardware, en die ondersteund het toch al, en zijn de meerkosten van het gebruik van ECC nihil, ten opzichte van de kosten van als de pilaar van het IT systeem faalt.

Neemt niet weg dat ik voorstander ben van ECC als het budget het toelaat, maar de meeste thuisgebruikers, bouwen hun server op een budget, of vaak met hergebruikte hardware.

Ook adviseer ik een ieder die een non-ECC systeem bouwt om gewoon wekelijks met memtest86 het geheugen te testen, door wekelijks automatisch een klein command line scriptje te draaien.

[Q]

Silent data corruptie door het disk subsystem is net zo reel als geheugen corruptie door ECC geheugen. Maar de kans dat je thuis door een van beiden issues wordt getroffen is gewoon klein. Maar niet nul.

Het risico is zo klein, dus mensen grijpen dat feit aan om 150 euro te kunnen besparen op hun auto door de gordels dan maar weg te laten. Maar, roepen de anderen, neem dan wel de airbag die is toch gratis, ben je toch 'veiliger'.

Als jij er voor kiest om zonder gordels te rijden, dan ga je er dus vanuit dat je geen ongeluk gaat krijgen. Anders doe je dat niet, want je weet wat de consequenties kunnen zijn. Maar als je er vanuit gaat dat je toch geen ongeluk krijgt, dan is die airbag niet meer relevant. Want als je geen ongeluk gaat krijgen, heb je ook geen airbag nodig. Als dan de keuze voor een airbag, ondanks dat deze gratis is, wel je auto keuze beperkt, tot auto's waar je nog nooit mee hebt gereden, wat dan?

Als je er voor kiest om risico's kleiner dan 1 op 10.000 niet af te dekken, waarom dan toch de een wel doen en de ander niet? Puur omdat de een gratis is en de ander niet?

Maar zo gratis is ZFS niet: niet iedereen is bedreven in FreeBSD of Linux. En je moet wel wat kennis en ervaring hebben om de boel te kunnen beheren, zeker als het een keer fout gaat. Veel mensen hebben die kennis niet en ik betwijfel sterk of een FreeNAS of ZFSguru daar erg bij helpt.

Als je zojuist hebt besloten dat een bepaalde klasse van risico's gewoon niet relevant voor je is, dan kunnen DIY NAS bouwers beter focussen op dat wat binnen die gegeven context wel belangrijk voor hen is.

Ik zou dan zeggen: kies een oplossing die bij jouw ervaring en expertise past. Focus op jouw kunnen om eventuele problemen op te lossen als die ontstaan.

Je kunt je afvragen waarom je dit hele argument ook niet kunt toepassen op de situatie waarbij je ZFS weg laat en toch met ECC geheugen gaat draaien. Is dat niet net zo hypocriet?

In zekere zin wel, maar het heeft geen enkele impact op iemands platform keuze, alleen op je portemonnee. Of je nu twee ECC of non-ECC reepjes geheugen in een moederbord moet stoppen, dat maakt niet zoveel uit. Voor de een maakt de platform keuze niet zoveel uit, voor de ander is die 150 euro geen probleem voor weer anderen is beiden geen issue.

Het gaat mij veel meer om de totale context van wat voor iemand de beste DIY NAS oplossing is dan puur sec stellen "ZFS beschermt tegen data corruptie en legacy file systems niet dus je bent altijd 'beter' af met ZFS" is enorm kort door de bocht. Ik denk dat er dan toch een groep mensen eigenlijk onnodig boven hun kunnen gaat grijpen terwijl voor hun een Windows build misschien wel beter was geweest.

Neemt niet weg dat ik voorstander ben van ECC als het budget het toelaat, maar de meeste thuisgebruikers, bouwen hun server op een budget, of vaak met hergebruikte hardware.

Dat laatste valt ook in feite gewoon onder budget. Het is puur een centen kwestie. En soms is het beste advies voor mensen precies het advies wat ze niet willen horen. Dat ze niet voor een dubbeltje op de eerste rang kunnen zitten. Daar maak je je misschien niet populair mee. Maar het is wel eerlijk.

Dat wil niet zeggen dat de wereld vergaat als ze zonder ECC of ZFS of beiden draaien, maar wij zijn niet de genen die aan anderen gaan vertellen welke risico's ze wel of niet moeten nemen. Ik vind dat mensen zelf een geïnformeerde keuze moeten maken.

Het is beter om van een best-case scenario uit te gaan. Kwaliteit hardware, ECC geheugen, ZFS. En dan naar gelang iemands situatie kunnen mensen zelf keuzes maken en gaan bezuinigen op bepaalde zaken. Maar dan geef je mensen zelf het stuur in handen.

Ook adviseer ik een ieder die een non-ECC systeem bouwt om gewoon wekelijks met memtest86 het geheugen te testen, door wekelijks automatisch een klein command line scriptje te draaien.

Hoeveel mensen die amper FreeNAS of ZFSguru geïnstalleerd krijgen hier zie jij dit ooit doen? Nog los van de rationaliteit er van? Kijk nou eens naar het publiek wat in het DIY NAS topic langs komt. Het gaat niet puur om de techniek, ken ook je publiek.
Just die mensen zijn helemaal 10x beter af om dan juist met ECC geheugen te draaien.

[player-x]

Q schreef op zaterdag 12 december 2015 @ 17:56:
Het risico is zo klein, dus mensen grijpen dat feit aan om 150 euro te kunnen besparen op hun auto door de gordels dan maar weg te laten. Maar, roepen de anderen, neem dan wel de airbag die is toch gratis, ben je toch 'veiliger'.

Als je er voor kiest om risico's kleiner dan 1 op 10.000 niet af te dekken, waarom dan toch de een wel doen en de ander niet? Puur omdat de een gratis is en de ander niet?

Elke keer dat ik jouw redenering lees, denk ik steeds dat je van de verkeerde aannames uit gaat.

De kans op een onherstelbare verlies van een array door corrupte disk met NTFS R5 is gewoon vele male hoger dan de schade een bitflip in het geheugen kan aanrichten, en de kans er op is de laatste jaren met grotere disks enorm gestegen, daar het risico kwadratisch om hoog gaat met de grote van disk, dit is geen aanname maar een praktijk feit, en hier is waar ZFS juist beter tegen bestand is.

En daarnaast ga je er van uitgaat dat alle data gelijk is voor thuis gebruik, bij bedrijven kan een bitflip, enorme schade aanrichten, bij thuis gebruik, is dat risico veel kleiner, daar bij de meeste mensen de bulk aan data gewoon gedownloade films zijn, waar als er een bitflip plaats zou vinden, en in meestal de gevallen alleen maar een glitch in de playback veroorzaakt.

Maar zo gratis is ZFS niet: niet iedereen is bedreven in FreeBSD of Linux. En je moet wel wat kennis en ervaring hebben om de boel te kunnen beheren, zeker als het een keer fout gaat. Veel mensen hebben die kennis niet en ik betwijfel sterk of een FreeNAS of ZFSguru daar erg bij helpt.

Tja het is natuurlijk nooit slim om in een keer over te stappen van je vertrouwde NTFS, naar ZFS, mijn eerste ZFS array, waren zes 160GB test schrijven, waar ik eerst mee heb gespeeld, voordat ik live over ging op ZFS voor een productie systeem.

En dergelijke schijven worden regelmatig goedkoop aangeboden.

V&A aangeboden: Partijtje 3,5'' SAS disken (15 stuks) samen voor EUR 60

En als je klaar bent met testen kan ze ook gemakelijk verkopen (vaak) voor de zelfde prijs.

Je kunt je afvragen waarom je dit hele argument ook niet kunt toepassen op de situatie waarbij je ZFS weg laat en toch met ECC geheugen gaat draaien. Is dat niet net zo hypocriet?

Wat is er hypocriet aan om een server te bouwen, waar je de voordelen van een betrouwbaar file systeem gebruikt, tegen een laag budget, want niet iedereen heeft het geld om een +50TB server te bouwen zoals jij een ik, samen met ECC geheugen.

In zekere zin wel, maar het heeft geen enkele impact op iemands platform keuze, alleen op je portemonnee. Of je nu twee ECC of non-ECC reepjes geheugen in een moederbord moet stoppen, dat maakt niet zoveel uit. Voor de een maakt de platform keuze niet zoveel uit, voor de ander is die 150 euro geen probleem voor weer anderen is beiden geen issue.

En voor weer andere, bouwen ze hun systeem van gratis hergebruikte hardware, en is 200 a 300 euro extra gewoon veel geld!

Ik denk dat er dan toch een groep mensen eigenlijk onnodig boven hun kunnen gaat grijpen terwijl voor hun een Windows build misschien wel beter was geweest.

Daar is zeker wat voor te zeggen, zeker als iemand niet de tijd er in wil steken, zijn ze gewoon beter af met een Windows build, maar als je wel de tijd er in wil stekken om ZFS te leren, ben je daar gewoon beter mee af dan een NTFS systeem qua veiligheid.

Imho ben je gewoon te veel een purist, en ga je te veel voorbij aan hoe thuis gebruikers hun server willen gebruiken, en kijk je veel te veel met wat jij denkt dat mensen moeten doen in jouw ogen, maar sorry, maar ik kan er nog steeds niet met je eens hier over zijn.

[Q]

player-x schreef op zaterdag 12 december 2015 @ 22:37:
[...]

Elke keer dat ik jouw redenering lees, denk ik steeds dat je van de verkeerde aannames uit gaat.

De kans op een onherstelbare verlies van een array door corrupte disk met NTFS R5 is gewoon vele male hoger dan de schade een bitflip in het geheugen kan aanrichten, en de kans er op is de laatste jaren met grotere disks enorm gestegen, daar het risico kwadratisch om hoog gaat met de grote van disk, dit is geen aanname maar een praktijk feit, en hier is waar ZFS juist beter tegen bestand is.

De kans dat je door een URE thuis een array gaat verliezen is enorm klein, laten we eerlijk zijn. Al die paniek over URE specificaties: iedere scrub bij mij wel een URE zou moeten tegen gekomen maar ik zie ze nooit. En ik heb het hier oven 40+ TB aan data over 2 ZFS systemen die dan iedere keer gelezen wordt.

En de UREs zijn niet eens echt interessant want dat zijn errors die nog door de storage worden opgemerkt. Legacy RAID kan daar niet zo goed mee omgaan als je al disk uitval hebt met RAID 5, dan ben je de sjaak. Waar het 'echt' om gaat zijn de (silent) corrupte bitjes die er toch doorheen glippen. Die kans is erg klein, thuis.

En daarnaast ga je er van uitgaat dat alle data gelijk is voor thuis gebruik, bij bedrijven kan een bitflip, enorme schade aanrichten, bij thuis gebruik, is dat risico veel kleiner, daar bij de meeste mensen de bulk aan data gewoon gedownloade films zijn, waar als er een bitflip plaats zou vinden, en in meestal de gevallen alleen maar een glitch in de playback veroorzaakt.

Dat laatste is natuurlijk waar, maar dat is ook nooit het risico waar we ons druk over maken.

Het gaat natuurlijk om het *wegschrijven* van data, daar zit 'm de crux. Je kunt bij rot werkgeheugen niet meer vertrouwen dat de data die je naar je NAS stuurde ook goed is opgeslagen.

Niet zo heel erg bij een paar films, minder leuk als daardoor je backups silent corrupt raken. Ga je precies achter komen op het moment dat je die backups het hardst nodig hebt.

Zeker niet eerder, zelfs niet met ZFS want ZFS ziet dat niet eens. Op een gegeven moment kan rot geheugen CRC errors geven als je ZFS draait, maar aangezien 90% van het publiek hierzo toch vergeet om alarmering per email in te schakelen duurt het nog weken voordat ze een keer merken wat er aan de hand is.

Daarom zou ik het publiek in dit geval zeker tegen zichzelf in bescherming willen nemen (maar hier wel open over zijn).

Wat is er hypocriet aan om een server te bouwen, waar je de voordelen van een betrouwbaar file systeem gebruikt, tegen een laag budget, want niet iedereen heeft het geld om een +50TB server te bouwen zoals jij een ik, samen met ECC geheugen.

Het is niet hypocriet. Maar het is niet zo relevant. Als je comfortabel zonder gordels durft te rijden, waarom maak je je dan druk om een airbag?

Je kunt je beter dan druk maken over andere zaken die je belangrijk vind voor een NAS. Wil je extra software draaien? Etc.

Ik denk dat mensen met een krap budget bijvoorbeeld ook kunnen overwegen om een 2e hands kant-en-klare NAS (Synology/QNAP/etc) aan te schaffen. Zeker als je nog niet zo bedreven bent met ZFS en de platformen waar het op werkt.

Het gaat allemaal om context.

En voor weer andere, bouwen ze hun systeem van gratis hergebruikte hardware, en is 200 a 300 euro extra gewoon veel geld!

De perceptie ontstaat mogelijk dat je juist dankzij ZFS dus prima 'oud spul' kan gebruiken als NAS platform. Als dat oude spul geen ECC geheugen heeft, dan creëer je een vals gevoel van veiligheid. Juist bij oudere 2e hands hardware verwacht ik eerder rot geheugen dan bij nieuw spul.

Ik zou dan zeggen, laat zitten, hang gewoon een USB schijf aan je computer. Ben je stuk veiliger bezig.

Maar zolang mensen zich bewust zijn dat ze risico's nemen, is het wat mij betreft prima.

[player-x]

Q schreef op zondag 13 december 2015 @ 00:39:
De kans dat je door een URE thuis een array gaat verliezen is enorm klein, laten we eerlijk zijn. Al die paniek over URE specificaties: iedere scrub bij mij wel een URE zou moeten tegen gekomen maar ik zie ze nooit. En ik heb het hier oven 40+ TB aan data over 2 ZFS systemen die dan iedere keer gelezen wordt.

En de UREs zijn niet eens echt interessant want dat zijn errors die nog door de storage worden opgemerkt. Legacy RAID kan daar niet zo goed mee omgaan als je al disk uitval hebt met RAID 5, dan ben je de sjaak. Waar het 'echt' om gaat zijn de (silent) corrupte bitjes die er toch doorheen glippen. Die kans is erg klein, thuis.

Dus waar het op neer komt is dat jij zegt dat bv NTFS/ext4 RAID5/6 een beter alternatief is voor ZFS als je geen ECC hebt!

Maar je zegt ook dat URE's een probleem zijn voor Leagcy RAID, hoe kan je die twee stellingen verenigen?

Want er zijn echt genoeg HDDs die problemen hebben, ben er zelf genoeg tegen gekomen, maar als ik/je het
Check je SMART topic lees, zie ik iig dat ik niet de enige ben met probleem HDDs!

En in mijn ervaring, (+500 systemen gebouwd), ben ik zelf nog nooit defect geheugen tegen gekomen, een vriend van mij, zijn zoon werkt op een verzamel punt van elektronica, en daar komen heel veel bedrijfs PC's binnen, en daar haalt hij o.a. altijd het geheugen uit, gemiddeld zo een 50 stuks per maand, dat hij op de bekende verschillende plaatsen weer verkoopt, als extra zakcentje, en voorheen testen hij dat geheugen voor dat hij het verkocht, maar hij is met testen gestopt na een half jaar, omdat hij nooit problemen tegen kwam, en heeft nadien (doet dat al 3j) ook nooit defect geheugen terug gekregen.

HDDs daar in tegen, waar hij ook in handelt, gooit hij zo een 30% van weg, van wegen SMART error's, ik zou dus best de stelling willen verdedigen dat het overgrote probleem bij opslag ligt, en niet het geheugen.

En zelfs in een non-ECC systeem je veiliger af bent met ZFS, dan NTFS/ext4 raid.

[Q]

Dus waar het op neer komt is dat jij zegt dat bv NTFS/ext4 RAID5/6 een beter alternatief is voor ZFS als je geen ECC hebt!

Nee, ik zeg dat de keuze voor NTFS of ZFS gewoon effectief niet uitmaakt als je toch niet zo om data integriteit geeft (door ECC weg te laten). Er zijn dan misschien andere zaken waar je je beter druk over kunt maken.

Ik denk oprecht dat als iemand een Windows server met ECC geheugen draait en zijn windows apps en een 'echte' hardware RAID controller ook anno 2015 een prima betrouwbaar en veilig systeem neerzet. Niet zo veilig voor je data als met ZFS mogelijk was geweest, maar betrouwbaar genoeg voor thuis. Dat is overigens de keuze van veel grote storage builds in het 20+ TB show-off topic.

Het is natuurlijk fantastisch als je mensen met een beperkt budget wijs kunt maken dat ze beter ZFS kunnen toepassen no matter what de context is. Want het is veiliger!!!

Om ze vervolgens op de goedkoopste van het goedkoopste hardware te laten draaien (met no-name voedingen en weet ik veel wat aan troep) en bij sommigen zonder de kennis en ervaring die nodig is om er mee om te gaan.

Prima hoor, maar waar liggen je prioriteiten nu als NAS bouwer?

Dan iets over disks. Ik zie weinig reactie over mijn URE stukje, ik neem aan dat je je daar dus wel in kunt vinden. Maar dat maakt meteen ook duidelijk waarom het feit dat disks veel vaker uitvallen dan geheugen in mijn ogen niets betekent in de discussie over het belang van ZFS.

In 99/100 gevallen handelt legacy RAID UREs prima af. Toegegeven, wat ham-fisted, maar dat maakt niet zoveel uit. Het gaat juist om dat ene incident waarbij je juist *geen* smart errors ziet en de disk prima werkt, maar wel data onjuist opslaat of corrupt retourneert. In dat geval zal ZFS verschil maken. De kans dat je met een URE te maken hebt is veel groter dan een situatie van silent data corruptie waarbij ZFS je zal 'redden'.

Dan wat RAM betreft, je bent prima bekend met de Google en Amazon studies over hoe frequent single-bit errors worden afgevangen. Dat die zoon nooit ellende heeft gezien met geheugen, soit. Moeten mensen nu werkelijk hun keuzes gaan baseren op anekdotes? Voor zover ik er mee te maken gehad heb, heb ik in mijn leven een desktop/laptop of 5 schat ik mijn handen gehad die niet meer door memtest kwam. Kleine aantallen. Dat waren desktops/laptops.

Maar je NAS staat meestal 24/7 aan zoals een 'echte' server (wat het is) en dat vergroot de risico's al substantieel.

En - ja daar is hij weer - juist voor de mensen met weinig budget is de HP Proliant Microserver Gen 8 natuurlijk een uitkomst.
Je kunt er 4 disks in kwijt en met 4 GB extra geheugen voor een totaal van 8 zit je op 260 euro exclusief disks.

Als je dat soort bedragen er niet voor over hebt dan is je data je dus echt niets waard wat mij betreft.

#	Product	Prijs	Subtotaal
1	Kingston ValueRAM KVR13LE9S8/4	€ 33,37	€ 33,37
1	HP Proliant MicroServer Gen8 G1610T	€ 227,50	€ 227,50
Bekijk collectie Importeer producten		Totaal	€ 260,87

Klik eens een vergelijkbaar non-ECC systeem bij elkaar en laten we eens kijken wat dan werkelijk het prijsverschil is.

[ Voor 3% gewijzigd door Q op 14-12-2015 00:26 ]

[player-x]

Q schreef op maandag 14 december 2015 @ 00:18:
Nee, ik zeg dat de keuze voor NTFS of ZFS gewoon effectief niet uitmaakt als je toch niet zo om data integriteit geeft (door ECC weg te laten). Er zijn dan misschien andere zaken waar je je beter druk over kunt maken.

Dus jouw stelling is toch, dat er geen verschil is tussen NTFS en ZFS op een non ECC systeem, en de zelf controlerende functie door het file systeem niet meer werkt omdat je geen ECC gebruikt!

Het is natuurlijk fantastisch als je mensen met een beperkt budget wijs kunt maken dat ze beter ZFS kunnen toepassen no matter what de context is. Want het is veiliger!!!

Om ze vervolgens op de goedkoopste van het goedkoopste hardware te laten draaien (met no-name voedingen en weet ik veel wat aan troep) en bij sommigen zonder de kennis en ervaring die nodig is om er mee om te gaan.

Waar hebben we het hier over rommel gebruiken, je moet nu niet opeens met false argumenten komen waar we het hier helemaal niet over hebben.

We hebben het over bv een thuis server gemaakt van een oude PC, iets dat best veel mensen doen, en dan de vraag is, heeft ZFS een toegevoegde veiligheidswaarde over NTFS.

Mijn stelling is dan, ja, mits je de tijd wilt nemen om te leren ZFS te gebruiken, en je je hardware test.

Dan wat RAM betreft, je bent prima bekend met de Google en Amazon studies over hoe frequent single-bit errors worden afgevangen. Dat die zoon nooit ellende heeft gezien met geheugen, soit. Moeten mensen nu werkelijk hun keuzes gaan baseren op anekdotes? Voor zover ik er mee te maken gehad heb, heb ik in mijn leven een desktop/laptop of 5 schat ik mijn handen gehad die niet meer door memtest kwam. Kleine aantallen. Dat waren desktops/laptops.

Mijn ervaring is heel anders, en je hebt heel veel pech gehad, of heel veel geheugen getest.

Maar ik heb ongeveer 500 setjes geheugen getest met met PassMark en MEMtest86 voor een systeem bij mij de deur uit ging, en de ongeveer 300 gebruikte setjes die hij heeft getest, laten een heel ander beeld zien, vooral als je het vergelijkt met de HDDs die ik heb gezien, en de 30% HDDs die hij ziet met SMART errors.

Maar je NAS staat meestal 24/7 aan zoals een 'echte' server (wat het is) en dat vergroot de risico's al substantieel.

Oooo, en hoe word het risico vergroot?, er is alleen maar een risico op het moment dat de data actief in het geheugen zit.

En - ja daar is hij weer - juist voor de mensen met weinig budget is de HP Proliant Microserver Gen 8 natuurlijk een uitkomst.

Klik eens een vergelijkbaar non-ECC systeem bij elkaar en laten we eens kijken wat dan werkelijk het prijsverschil is.

Het verschil is 260 euro ten opzichte van een hergebruikte PC, voor veel mensen toch echt behoorlijk wat geld!

[begintmeta]

Of ZFS zinvol is hangt ook van de data/applicaties af,ɪᴍʜᴏ, metadatacontrole blijft natuurlijk altijd zinvol voor een fs, maar dat komt iets vaker voor dan datacontrole (door het fs)

[ Voor 38% gewijzigd door begintmeta op 14-12-2015 10:51 ]

[Q]

player-x schreef op maandag 14 december 2015 @ 10:13:
Dus jouw stelling is toch, dat er geen verschil is tussen NTFS en ZFS op een non ECC systeem, en de zelf controlerende functie door het file systeem niet meer werkt omdat je geen ECC gebruikt!

Nee dat is mijn stelling niet. Je moet even uitzoomen. Ik maak een 'meta-argument'.

Het feit dat ZFS veiliger is voor je data dan NTFS is in de genoemde context niet relevant.

Prima als je bewust toch voor ZFS kiest. Ook prima als je het niet doet. Absolute data integriteit is gewoon in die context niet het belangrijkste voor je.

Een auto met 2 wiel aandrijving is een prima auto. Een auto met vier wiel aandrijving is 'beter'.
Als ik niets om 4 wiel aandrijving geef, omdat 2 wiel aandrijving goed genoeg vind, dan is het feit dat 4 wiel aandrijving 'beter' is niet relevant.

Ik ben blij dat je niet ontkent trouwens dat een Windows server met hardware RAID controller een prima stabiel systeem kan zijn en dus ook een redelijke optie is, als mensen dat willen (beter bij je past). Niet zo goed als ZFS toe passen, maar een redelijke optie.

Mijn ervaring is heel anders, en je hebt heel veel pech gehad, of heel veel geheugen getest.
Maar ik heb ongeveer 500 setjes geheugen getest met met PassMark en MEMtest86 voor een systeem bij mij de deur uit ging, en de ongeveer 300 gebruikte setjes die hij heeft getest, laten een heel ander beeld zien, vooral als je het vergelijkt met de HDDs die ik heb gezien, en de 30% HDDs die hij ziet met SMART errors.

En dat zijn slechts moment opnamen, een eemalige test. Ik heb geen interesse in anekdotes, maar wel in wetenschappelijk verantwoorde studies.

Oooo, en hoe word het risico vergroot?, er is alleen maar een risico op het moment dat de data actief in het geheugen zit.

Er is risico iedere keer dat er een write naar een file system plaats vindt nog los van de grotere context dat een bitflip ook kernel code kan treffen en dat kan helemaal verkeerd uitpakken. Ga je echt deze discussie voeren?

Het verschil is 260 euro ten opzichte van een hergebruikte PC, voor veel mensen toch echt behoorlijk wat geld!

Voor die mensen is data integriteit dus niet het aller belangrijkste, prima.

Laten we eens uitgaan van iemand die geen oude hardware heeft en iets nieuws wil aanschaffen op een budget, zo goedkoop mogelijk, non-ECC om de kosten laag te houden.

Voorstelletje:

#	Product	Prijs	Subtotaal
1	ASRock Q1900DC-ITX	€ 103,-	€ 103,-
1	Sharkoon MS120	€ 33,95	€ 33,95
1	Crucial CT102464BF160B	€ 37,-	€ 37,-
1	be quiet! System Power 7 300W	€ 32,95	€ 32,95
Bekijk collectie Importeer producten		Totaal	€ 206,90

Dus dan wordt het prijsverschil 60 euro grofweg. Als dat er niet van af kan dan weet ik het niet meer.

Wil je een setup met meer disks dan moet je naar de 150 euro ECC moederborden, maar dan gaat die meerprijs ook redelijk wegvallen tegen de prijs van de totale setup.

[ Voor 28% gewijzigd door Q op 14-12-2015 12:53 ]

[FireDrunk]

Wat is in jou geval de ECC tegenhanger dan? Want een Q1900 doet toch geen ECC? Of doel je daarmee op een HP Microserver?

(Ik zit nu zelf toevallig naar de nieuwe Supermicro X11SSL-CF serie te kijken.)
http://www.supermicro.nl/...n/C236_C232/X11SSL-CF.cfm

[ Voor 39% gewijzigd door FireDrunk op 14-12-2015 13:43 ]

[player-x]

Q schreef op maandag 14 december 2015 @ 12:40:
Het feit dat ZFS veiliger is voor je data dan NTFS is in de genoemde context niet relevant.

Ik denk dat het voor eindgebruikers super relevant is, dat ZFS zelfs zonder ECC veiliger is dan NTFS!

Prima als je bewust toch voor ZFS kiest. Ook prima als je het niet doet. Absolute data integriteit is gewoon in die context niet het belangrijkste voor je.

We hebben het niet over absoluten, maar over thuis servers, die met ZFS een gevaren schakel weg neemt, uit de risico keten, als jij dat irrelevant vind moet jij dat weten maar de meeste thuis eindgebruikers is het zeker wel relevant.

Een auto met 2 wiel aandrijving is een prima auto. Een auto met vier wiel aandrijving is 'beter'.
Als ik niets om 4 wiel aandrijving geef, omdat 2 wiel aandrijving goed genoeg vind, dan is het feit dat 4 wiel aandrijving 'beter' is niet relevant.

Weer haal je dingen door elkaar, een betere stelling zou zijn, als je kan kiezen tussen twee gelijke een auto's voor het zelfde geld, een met ABS en een zonder, dan zou jij de auto zonder nemen, want er zit geen traction control op, dus je hebt niet de optimale veiligheid die je kan hebben.

Imho een hele rare redenering.

uiteraard is traction control (lees ECC) zeker wenselijk, maar als wat je kan komen het niet heeft, dan kies ik nog steeds de auto met ABS (lees ZFS), voor de extra veiligheid die het levert.

En dat zijn slechts moment opnamen, een eemalige test. Ik heb geen interesse in anekdotes, maar wel in wetenschappelijk verantwoorde studies.

Vind 500 nieuwe en 300 oude samples, een groot genoeg pool, om daar redelijke conclusies uit te trekken, zeker als je de flinke failure rate van 30% HDDs tegenover zet van PCs van gemiddeld 5j oud.

Is het wetenschappelijk, nee, is het groot genoeg dat elk redelijk persoon er conclusies uit kan trekken waar hij/zij een redelijke afweging mee kan maken, ik zou dan ja zegen.

Er is risico iedere keer dat er een write naar een file system plaats vindt nog los van de grotere context dat een bitflip ook kernel code kan treffen en dat kan helemaal verkeerd uitpakken. Ga je echt deze discussie voeren?

Weer zo een rare conclusie, ja je hebt gelijk dat het risico er is, maar dat geld net zo hard voor een OS dat 24/7 draait met NTFS/ext4, dus als alles gelijk is, heb je nog steeds het voordeel van een zelf controlerende filesysteem, en zit er om die reden nog steeds geen nadeel aan om ZFS te gebruiken over NTFS.

Voor die mensen is data integriteit dus niet het aller belangrijkste, prima.

Waarom heb jij het de hele tijd over absoluten, er zit ook een midden weg tussen, waar mensen kiezen om de betere oplossing te kiezen inplaats van de allerbeste, want de allerbeste kost gewoon extra geld, wat niet iedereen (er voor over) heeft.

Laten we eens uitgaan van iemand die geen oude hardware heeft en iets nieuws wil aanschaffen op een budget, zo goedkoop mogelijk, non-ECC om de kosten laag te houden.

Ja, en dan nog zijn ze beter af met ZFS dan met NTFS.

Want onder de streep heeft ZFS een zelf controlerend file systeem, en Windows heeft het niet.

Als iemand mij vraagt, deze hardware heb ik nog, of heb ik gekocht, en zij vragen mij dan welk filesysteem kan ik het beste gebruiken, is mijn antwoord simpel, ''gebruik ZFS, mits je berijd bent om er werk inte steken om het te leren''.

Vraagt iemand me, ''Ik wil een home server bouwen, welke hardware moet ik kopen'', dan is mijn antwoord, '' ik zou je sterk aan raden om 125 euro extra uit te geven en een ECC systeem bouwen als je ZFS wilt gebruiken, en berijd bent om te leren er mee om te gaan''

Jij maakt het zo zwart/wit, door in absoluten te werken, ipv naar de praktijk te kijken, en te kijken wat is voor dat persoon de beste afweging, her gebruiken van hardware of nieuwe ECC hardware.

[Q]

player-x schreef op maandag 14 december 2015 @ 13:48:
[...]

Ik denk dat het voor eindgebruikers super relevant is, dat ZFS zelfs zonder ECC veiliger is dan NTFS!

Het is niet relevant genoeg om daar persé de keuze van je NAS platform van af te laten hangen. Mensen hoeven zich niet blind te staren op ZFS in die context.

Weer haal je dingen door elkaar, een betere stelling zou zijn, als je kan kiezen tussen twee gelijke een auto's voor het zelfde geld, een met ABS en een zonder, dan zou jij de auto zonder nemen, want er zit geen traction control op, dus je hebt niet de optimale veiligheid die je kan hebben.

Als je ECC ziet als ABS en ZFS als traction control ben ik het eens met je analogie.
Als je toch zonder ABS rijdt, waarom zou je je dan perse druk maken over traction control?

Beter is om dan te kijken naar andere eigenschappen die je belangrijk vindt.

Is het wetenschappelijk, nee, is het groot genoeg dat elk redelijk persoon er conclusies uit kan trekken waar hij/zij een redelijke afweging mee kan maken, ik zou dan ja zegen.

Nee, het feit dat het geen onderzoek is die aan de juiste voorwaarden voldoet betekent precies dat je gewoon geen conclusies kunt trekken, ook deze niet.

FireDrunk schreef op maandag 14 december 2015 @ 13:42:
Wat is in jou geval de ECC tegenhanger dan? Want een Q1900 doet toch geen ECC? Of doel je daarmee op een HP Microserver?

(Ik zit nu zelf toevallig naar de nieuwe Supermicro X11SSL-CF serie te kijken.)
http://www.supermicro.nl/...n/C236_C232/X11SSL-CF.cfm

De Q1900 is een voorbeeld van een platformpje dat geen ECC doet en dus ongeveer 60 euro goedkoper is. Het is dus inderdaad de tegenhanger van de HP Microserver.

[ Voor 17% gewijzigd door Q op 14-12-2015 18:22 ]

[player-x]

Q schreef op maandag 14 december 2015 @ 14:30:
Het is niet relevant genoeg om daar persé de keuze van je NAS platform van af te laten hangen. Mensen hoeven zich niet blind te staren op ZFS in die context.

Heb ik ook nooit gezegd, alleen jij zegt, als je geen ECC neemt, kan je net zo goed geen ZFS nemen, daar zonder ECC, ZFS nouwelijks een toegevoegde waarde aan je FS is.

Als je ECC ziet als ABS en ZFS als traction control ben ik het eens met je analogie.
Als je toch zonder ABS rijdt, waarom zou je je dan perse druk maken over traction control?

Beter is om dan te kijken naar andere eigenschappen die je belangrijk vindt.

Nee mijn keuze van woorden was bewust correct, de kans op geheugen fouten, veel kleiner dan de kans op HDD fouten, dus de zelf corrigerende manier waar op ZFS werkt is imho veel belangrijkere toevoeging, dan wat ECC brengt.

Nee, het feit dat het geen onderzoek is die aan de juiste voorwaarden voldoet betekent precies dat je gewoon geen conclusies kunt trekken, ook deze niet.

Zou ook niet zeggen dat het een feitelijke indicatie is, maar de sample is groot genoeg om redelijk te bevestigen wat ik ook uit andere bronnen heb opgemaakt.

De Q1900 is een voorbeeld van een platformpje dat geen ECC doet en dus ongeveer 60 euro goedkoper is. Het is dus inderdaad de tegenhanger van de HP Microserver.

Zou de HP aan iedereen adviseren die een systeem wil bouwen tot 4 bays, en gewoon die 40 euro daarvoor gewoon neerlegden, ipv zelf te gaan bouwen.

Maar het is geen alternatief voor mensen die hardware hergebruiken, of meer dan 4 bays nodig hebben.

[FireDrunk]

Ik heb zelf ook zitten kijken naar een goedkope manier om een external cabinet te plaatsen aan een HP Microserver. Gewoon een SAS HBA met externe SAS poorten plaatsen, en daar externe devices aan hangen.

Helaas zijn er alleen maar idioot dure (lees: goedkoopste troep > 300 euro, redelijke kwaliteit > 500 euro) cabinets te krijgen. Dat is dus absoluut niet kosten efficient. Dan is een Supermicro of Ri-Vier chassis veel goedkoper.

[Q]

player-x schreef op maandag 14 december 2015 @ 19:01:
Heb ik ook nooit gezegd, alleen jij zegt, als je geen ECC neemt, kan je net zo goed geen ZFS nemen, daar zonder ECC, ZFS nouwelijks een toegevoegde waarde aan je FS is.

ZFS is wel veiliger voor je data dan NTFS, maar in de context is dat niet relevant. Er zijn belangrijkere zaken.

Nee mijn keuze van woorden was bewust correct, de kans op geheugen fouten, veel kleiner dan de kans op HDD fouten, dus de zelf corrigerende manier waar op ZFS werkt is imho veel belangrijkere toevoeging, dan wat ECC brengt.

Tja daar verschillen we dan erg over van mening.

De kans op het type HDD fouten (stille corruptie) waarbij ZFS meerwaarde biedt over NTFS/EXT3/XFS + software/hardware RAID is veel en veel kleiner dan jij doet voorkomen. De kans dat je thuis gered wordt is heel klein.

De risico's van ECC geheugen zijn uitermate goed gedocumenteerd in grootschalige studies. De kans dat jouw laptop of werkstation thuis dit jaar een keer gecrasht is door een tijdelijke bitflip is aanzienlijk.

Ik zou liever een server draaien op basis van ECC geheugen zonder ZFS dan andersom. Zeker mijn 71 TB server.

Het is gewoon een conceptueel ding: ik ga mij pas druk maken over de lagen er boven als het fundament goed is.

Zou ook niet zeggen dat het een feitelijke indicatie is, maar de sample is groot genoeg om redelijk te bevestigen wat ik ook uit andere bronnen heb opgemaakt.

Nee het is gewoon betekenisloos. Je test is niet relevant om genoemde redenen en bovendien was het maar een moment opname. Je kunt er niets uit bevestigen.

Zou de HP aan iedereen adviseren die een systeem wil bouwen tot 4 bays, en gewoon die 40 euro daarvoor gewoon neerlegden, ipv zelf te gaan bouwen.

Maar het is geen alternatief voor mensen die hardware hergebruiken, of meer dan 4 bays nodig hebben.

De mensen die het geld er niet voor over hebben die moeten maar zien wat ze doen. Maar ze moeten niet in de waan leven dat ze dan zonodig toch ZFS moeten draaien omdat dit 'beter' is. Dat is een veel te nauwe visie.

De mensen die meer dan 4 drives kwijt moeten besteden meer geld aan drives en dan kom je snel op een punt dat de meerprijs van ECC geheugen gewoon niet meer iets is waar je je echt druk over maakt. Dan ben je vaak ook zo serieus met je NAS bezig dat je er voor wilt gaan en iets knaps neer wilt zetten. Dan is de meerprijs over de periode dat zo'n systeem staat gewoon een afrondingsfout.

Als je met ECC geheugen draait, dan vindt ik het conceptueel zinvol om ook ZFS te overwegen.

Ik sluit even af met de beroemde quote van Matthew Ahrens, co-founder van ZFS:

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

Maar ik vind het verder wel best zo, ik val in herhaling. Je mag het laatste woord hebben

[player-x]

Q schreef op maandag 14 december 2015 @ 20:40:
ZFS is wel veiliger voor je data dan NTFS, maar in de context is dat niet relevant. Er zijn belangrijkere zaken.

Nee jij vind dat er belangrijkere zaken zijn, dat is heel wat anders.

Ik zou liever een server draaien op basis van ECC geheugen zonder ZFS dan andersom. Zeker mijn 71 TB server.

Het is gewoon een conceptueel ding: ik ga mij pas druk maken over de lagen er boven als het fundament goed is.

Kijk daar zijn we nogmaals weer, jij bent een purist, ik en bv CiPHER, zijn wat dat gewoon praktischer dan jij, dat op zich is nog prima, maar probeer het dan iig niet zo te brengen, alsof ZFS onveiliger is dan NTFS als je geen ECC gebruikt, want dan loop je alleen maar FUD rond te strooien!

Nee het is gewoon betekenisloos. Je test is niet relevant om genoemde redenen en bovendien was het maar een moment opname. Je kunt er niets uit bevestigen.

Als jij de test van 800 samples betekenis loos vind, hoeveel moeten het er dan wel niet zijn voordat het wel betekenisvol wordt, voor mij is het toch echt een goede indicatie dat er geen groot probleem is met onbetrouwbaar geheugen, de problemen die ik tegen kom liggen keer op keer bij de HDDs, die gewoon een stuk minder betrouwbaar zijn.

De mensen die het geld er niet voor over hebben die moeten maar zien wat ze doen. Maar ze moeten niet in de waan leven dat ze dan zonodig toch ZFS moeten draaien omdat dit 'beter' is. Dat is een veel te nauwe visie.

De mensen die meer dan 4 drives kwijt moeten besteden meer geld aan drives en dan kom je snel op een punt dat de meerprijs van ECC geheugen gewoon niet meer iets is waar je je echt druk over maakt. Dan ben je vaak ook zo serieus met je NAS bezig dat je er voor wilt gaan en iets knaps neer wilt zetten. Dan is de meerprijs over de periode dat zo'n systeem staat gewoon een afrondingsfout.

Als je met ECC geheugen draait, dan vindt ik het conceptueel zinvol om ook ZFS te overwegen.

Jep laaten we hier maar over zeggen dat we het eens zijn dat we het oneens met elkaar zijn!

Ik sluit even af met de beroemde quote van Matthew Ahrens, co-founder van ZFS:

Als je iemand quote, quote hem dan wel volledig, en ga niet een beetje aan quote cherry picking doen, want dan doe je het zelfde als Creatisten met hun Intelligent Design BS.

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.

Dus als alles gelijk is, is ZFS net zo (on)gevoelig voor ECC errors als alle andere file systemen, dus aub, probeer dat feitje niet te verdraaien, omdat dat op die manier beter bij jouw mening past!

[old_spice]

Even los van de prijs, is het heel veel beter om een NAS te bouwen met ZFS en ECC geheugen, of is het verschil te verwaarlozen? Er van uit gaande dat apparaten zonder ECC geheugen data opslaan op de NAS.

[FireDrunk]

Als je de rest van het topic gewoon even leest, kan je zelf achter dat antwoord komen

[Q]

Ik heb het antwoord niet gevonden.

Dit was mijn antwoord 'destijds':

ECC geheugen beschermt tegen data corruptie door rot werkgeheugen (risico X)
ZFS beschermt tegen data corruptie door rotte harde schijven (risico Y).

Geen van beide technologieën beschermt tegen client-side corruptie van data die vervolgens al corrupt wordt aangeleverd aan de ZFS + ECC NAS (risico Z).

Dat ECC en ZFS niet beschermen tegen risico Z maakt ECC en ZFS niet minder waardevol. Want ze beschermen wel tegen andere risico's (X en Y).

http://gathering.tweakers...messages?data%5Bpage%5D=2

[ Voor 14% gewijzigd door Q op 20-12-2015 22:02 ]

[FireDrunk]

Goede samenvatting!

[Q]

Silent data corruptie
Harde schijven gebruiken intern ECC en belangrijker Reed-Solomon encoding om foute data te corrigeren.
Er moet dus best wat mis zijn voordat een harde schijf een read error geeft. En de kans dat een schijf zelf corrupte data retourneert zonder foutmeldingen is dus zeer klein, vanwege die checksums over een sector.

Ik heb nog wel eens zitten zoeken maar over silent data corruptie is maar 1 goede studie van gedaan.
Over hoe vaak ECC geheugen zijn werk moet doen zijn meer studies te vinden.

https://www.usenix.org/le...daram/bairavasundaram.pdf

Van de 1.8 miljoen disks waren er 365 disks die silent data corruptie laten zien (dus dat de RAID laag de corruptie mist). Dat is een risico van 1 op 4191. Als we dan er vanuit gaan dat zeg 300 van die disks de 358000 SATA disks betrof, dan praten we van een risico van 1 op 1193 over een periode van 17 maanden.

De kans op RAM geheugen fouten is veel groter.

Zoals ik eerder schreef, als ik moest kiezen tussen ofwel ZFS ofwel ECC geheugen dan zou ik dus voor ECC geheugen kiezen.

[ Voor 18% gewijzigd door Q op 05-01-2016 17:25 ]

[player-x]

Q schreef op dinsdag 05 januari 2016 @ 17:23:
De kans op RAM geheugen fouten is veel groter.

Niemand die zegt dat ECC niet absoluut noodzakelijk is zal ontkennen dat ECC het risico aanzienlijk verkleint.

Zoals ik eerder schreef, als ik moest kiezen tussen ofwel ZFS ofwel ECC geheugen dan zou ik dus voor ECC geheugen kiezen.

Wederom, de keuze is niet tussen ZFS plus ECC en NTSF/ext4 zonder ECC.

Maar als men op een budget zit, tussen een (her gebruikt) non ECC systeem met ZFS of NTFS/ext4, als men geen problemen heeft met het draaien van server Linux type OS, dan is ZFS de betere optie dan ext4.

Dat het beter is dat men ECC gebruikt weet iedereen die geen n00b is ook wel, is ook de reden dat ik bv zelf ook ECC gebruik, maar niet iedereen heeft het geld om een ECC systeem te bouwen, vooral als men hardware hergebruikt, is het prijsverschil enorm groot.

Net zo als iedereen weet dat als ze een Kai kopen, ze niet de zelfde betrouwbaarheid krijgen als wanneer een Lexus kopen, je krijgt waar je betaalt voor, maar als je gratis met wat extra werk, een betrouwbaarheids upgrade kan krijgen, is het uiteraard niet stom om het niet te doen.

[vanaalten]

Q schreef op dinsdag 05 januari 2016 @ 17:23:
Silent data corruptie
Ik heb nog wel eens zitten zoeken maar over silent data corruptie is maar 1 goede studie van gedaan.
Over hoe vaak ECC geheugen zijn werk moet doen zijn meer studies te vinden.

https://www.usenix.org/le...daram/bairavasundaram.pdf

Hmmm, "FAST ’08: 6th USENIX Conference on File and Storage Technologies" - een studie van 8 jaar oud met disks van zeker 10 jaar oud. In IT-tijd is dat wellicht niet zo interessant meer.

Van de 1.8 miljoen disks waren er 365 disks die silent data corruptie laten zien (dus dat de RAID laag de corruptie mist). Dat is een risico van 1 op 4191. Als we dan er vanuit gaan dat zeg 300 van die disks de 358000 SATA disks betrof, dan praten we van een risico van 1 op 1193 over een periode van 17 maanden.

Geen idee of het vergelijkbare uitkomsten gaat geven, maar laten we de schijfspecificatie van een moderne Western Digital 'green' schijf pakken:
'Non-recoverable read errors per bits read: <1 in 10¹⁴'
Ofwel, als je elke maand 1TB leest, dan zal je ongeveer 1 bit fout lezen gedurende 10 jaar.

Alleen hoe vergelijkt dat nou met geheugenfouten? Ik kwam wel deze studie tegen, maar ik kan er nog niet direct een vergelijkbaar getal uithalen: als je 1TB leest uit je RAM, hoeveel read errors heb je dan?
Hoe dan ook, de getallen die genoemd worden lijken zorgwekkend groot. Toch heb ik er in de praktijk nog nooit iets van gemerkt, denk ik.

De kans op RAM geheugen fouten is veel groter.

Zoals ik al schreef, ik zou die bit-errorrate van DDR geheugen wel eens op een vergelijkbare manier vergeleken willen zien. Goede statistiek die op eenzelfde manier te vergelijken is als de bit-error rate van harde schijven dus.

[Q]

Tja, wat mij betreft gaat het er in mijn post hierboven meer om waar de prioriteiten liggen als het om de bescherming van je data gaat. Goede hardware is in die context wat mij betreft het fundament, daar zou je prioriteit moeten liggen.

Verder snap ik de mentaliteit niet zo dat je wel data veiligheid wilt maar het mag vooral niets kosten. Alsof je data je geen euro waard is. Data veiligheid kost gewoon geld, linksom of rechtsom. Je kunt het niet realiseren zonder server hardware helaas.

ZFS draaien op (oudere) consumenten hardware is in mijn ogen net zo zinvol als airbags monteren in een auto waarvan de remmen het amper doen. Ik rij liever een auto zonder airbags maar met goede remmen dan andersom.

vanaalten schreef op dinsdag 05 januari 2016 @ 20:08:
[...]

Hmmm, "FAST ’08: 6th USENIX Conference on File and Storage Technologies" - een studie van 8 jaar oud met disks van zeker 10 jaar oud. In IT-tijd is dat wellicht niet zo interessant meer.

De studie is ouder, maar het is wat kort door de bocht om die dan zomaar af te schrijven. Disks zijn fundamenteel de afgelopen jaren niet zo enorm veranderd.

Dat disks nog steeds 1 op 10¹⁴ doen qua URE zegt denk ik iets: dat de betrouwbaarheid van disks niet is afgenomen. Een URE is natuurlijk geen silent data corruptie. Maar het is mogelijk een indicatie of ook de kans op silent data corruptie is toegenomen.

Geen idee of het vergelijkbare uitkomsten gaat geven, maar laten we de schijfspecificatie van een moderne Western Digital 'green' schijf pakken:
'Non-recoverable read errors per bits read: <1 in 10¹⁴'
Ofwel, als je elke maand 1TB leest, dan zal je ongeveer 1 bit fout lezen gedurende 10 jaar.

Nee, worst-case zie je een sector read-error iedere 12 TB. Dat zou dus ieder jaar 1 zijn. Maar een URE is geen silent data corruptie.

Alleen hoe vergelijkt dat nou met geheugenfouten? Ik kwam wel deze studie tegen, maar ik kan er nog niet direct een vergelijkbaar getal uithalen: als je 1TB leest uit je RAM, hoeveel read errors heb je dan?
Hoe dan ook, de getallen die genoemd worden lijken zorgwekkend groot. Toch heb ik er in de praktijk nog nooit iets van gemerkt, denk ik.

Zoals ik al schreef, ik zou die bit-errorrate van DDR geheugen wel eens op een vergelijkbare manier vergeleken willen zien. Goede statistiek die op eenzelfde manier te vergelijken is als de bit-error rate van harde schijven dus.

Dat is de befaamde Google-studie. Het is eigenlijk simpel. 8% van de geheugenreepjes heeft over de periode van een jaar op zijn minst 1 fout gezien. Een kans van ruwweg 1 op 13 dat een geheugen reepje dus een bit error zou zien. Stel dat de kans thuis wat kleiner is (de studie praat over zwaar belaste servers en bit fouten zijn gerelateerd aan de mate van belasting) dus maak de kans dan 1 op 130. Een factor 10 kleiner. Die silent data corruptie was dus 1 op ~1200.

Echter er is wel een punt: die 1 op 1200 gaat over een periode van 17 maanden = 1 jaar plus 5 maanden en die geheugen stats zijn per jaar. De stats voor silent data corruptie over 'slechts' een jaar zullen dus mogelijk nog wel positiever voor disks uitpakken.

Als je thuis geen ECC geheugen toepast dan weet je dus strikt genomen niet of je ooit door (tijdelijke) rotte RAM bits bent getroffen en of er nu data corrupt is. Net als dat je zonder ZFS niet weet of er misschien disk data corrupt is geraakt. Dat laatste was voor mij reden om ZFS te draaien als 'experiment'. Tot nu toe hebben zowel ECC geheugen als ZFS mij nog niet gered.

[ Voor 69% gewijzigd door Q op 05-01-2016 20:40 ]

[Verwijderd]

Als dataintegriteit niet van belang is, dan kan je af zonder ECC geheugen, is het van belang, dan wil je het overal, ook in je workstation.

Als je data belangrijk is, maar een lees foutje af en toe niet zo'n probleem en af en toe een enkel bestand met een klein foutje ook niet (bit flip in de meeste foto of video bestanden zie je niets van). Dan kan je je geld beter uitgeven aan een extra backup optie dan aan ECC. (als je moet kiezen!)

ZFS is altijd handig, vanwege de snapshots en ZFS send, ongeacht of je ECC geheugen gebruikt. En daarnaast sowieso veiliger dan NTFS en het OS is ook nog eens gratis.

Als je het geld hebt is het geen discussie, dan ga je sowieso voor ECC.

In mijn geval gaat het om een gedigitaliseerde collectie van al mijn DVDs en CDs van 'enkele' TB. die aan een media server geserveerd worden. Bitflips zijn niet belangrijk als ze een keer optreden en de data is ook niet heel belangrijk. Ik heb immers alle originelen nog, dus als het echt mis gaat kost het alleen tijd.

Toch heb ik een systeem met ZFS en ECC aangeschaft, ik heb het geld dus waarom niet het risico minimaliseren.

Ik heb onlangs mijn backup strategie aangepast voor de echt belangrijke data:
Ik zo'n 500 GB aan belangrijke onmisbare data (eigen fotos en filmpjes), deze worden offsite gebackuped, onsite gebackuped en ik heb extern gebrande Blu-rays met deze bestanden en parity informatie liggen (in meervoud)
Nog eens zo'n 500GB aan raw foto's die niet door de selectie zijn gekomen zijn alleen onsite gebackuped en op Blurays extern, de online backup bespaar ik me daarop.

Deze data vertrouw ik nooit aan een systeem toe die niet maximale risicomitigatie biedt. Vandaar dat het systeem is opgetrokken uit enterprise hardware. En ja mijn NAS draait daarom op een Xeon s2011 systeem, met een UPS en de hele shizzle ;-)

[Q]

Verwijderd schreef op dinsdag 05 januari 2016 @ 20:45:
Als dataintegriteit niet van belang is, dan kan je af zonder ECC geheugen, is het van belang, dan wil je het overal, ook in je workstation.

Eigenlijk wil je dat laatste ook, de meeste mensen doen dat niet, ECC is er helaas niet voor laptops.

Als je data belangrijk is, maar een lees foutje af en toe niet zo'n probleem en af en toe een enkel bestand met een klein foutje ook niet (bit flip in de meeste foto of video bestanden zie je niets van). Dan kan je je geld beter uitgeven aan een extra backup optie dan aan ECC. (als je moet kiezen!)

Backups zijn belangrijker dan ECC geheugen als je moet kiezen. Eens.

ZFS is altijd handig, vanwege de snapshots en ZFS send, ongeacht of je ECC geheugen gebruikt. En daarnaast sowieso veiliger dan NTFS en het OS is ook nog eens gratis.

Als je toch geen ECC geheugen doet vind ik de keuze voor ZFS vanwege de handige snapshot features en ZFS Send betere redenen om voor ZFS te kiezen, dan te stellen 'het is veiliger' dan NTFS. Zoals ik hierboven schets qua risico's: 'whatever'. Zolang mensen maar geen grote moeite doen en boven hun kunnen opereren om maar ZFS te kunnen draaien 'want het is veiliger'.

Er zitten wel wat 'verborgen' kosten aan ZFS.
http://louwrentius.com/th...fs-for-your-home-nas.html

Toch heb ik een systeem met ZFS en ECC aangeschaft, ik heb het geld dus waarom niet het risico minimaliseren.
En ja mijn NAS draait daarom op een Xeon s2011 systeem, met een UPS en de hele shizzle ;-)

Tja, je kiest er voor om te betalen voor wat nodig is om je doel te bereiken. Dat is per persoon een verschillende keuze.

[vanaalten]

Even vooropstellen dat ik eigenlijk niet zo'n sterke mening over ECC of ZFS heb, maar de berekeningen en getallen wel interessant vind.
Daarop door gaan:

Q schreef op dinsdag 05 januari 2016 @ 20:09:
Dat is de befaamde Google-studie. Het is eigenlijk simpel. 8% van de geheugenreepjes heeft over de periode van een jaar op zijn minst 1 fout gezien. Een kans van ruwweg 1 op 13 dat een geheugen reepje dus een bit error zou zien. Stel dat de kans thuis wat kleiner is (de studie praat over zwaar belaste servers en bit fouten zijn gerelateerd aan de mate van belasting) dus maak de kans dan 1 op 130. Een factor 10 kleiner. Die silent data corruptie was dus 1 op ~1200.

Echter er is wel een punt: die 1 op 1200 gaat over een periode van 17 maanden = 1 jaar plus 5 maanden en die geheugen stats zijn per jaar. De stats voor silent data corruptie over 'slechts' een jaar zullen dus mogelijk nog wel positiever voor disks uitpakken.

... weet ik niet of ik deze data zo relevant vind. Die 1 op 13 of zelfs 1 op 130 gaat over een bit-error in een geheugenreep gedurende een heel jaar (365 dagen van 24 uur van 3600 secondes enzo)

Stel dat we kijken naar de situatie die voor een NAS relevant is:
Je hebt een superbelangrijk databestand en dat stuur je voor langdurige betrouwbare opslag naar je NAS. Wanneer loop je dan precies risico's:

1. netwerkkabel richting NAS
2. in de geheugenelementen binnen de CPU (of raidcontroller kaarten enzo)
3. in het geheugen van de NAS: bitrot van de geheugenrepen
4. op de sata kabel richting disk
5. op de disk zelf: onder invloed van bitrot

Geen idee hoe de dataintegriteit bij (1) gecontroleerd wordt, zijn vast wel manieren te bedenken. (5) wordt met bijvoorbeeld ZFS of BTRFS gecheckt. (4) volgens mij ook. (3) met ECC, (2) zou ook nog een probleempunt kunnen zijn.
Maar wat volgens mij relevant is: de tijd dat het superbelangrijke databestand in het geheugen staat en vatbaar is voor bitfouten is zeer klein. Beetje afhankelijk van de snelheid van het netwerk misschien, maar ik zou gokken dat we over hooguit secondes praten.

Dus als je het dan hebt over een bitfout in een geheugenreep van 1 op 10², in een jaar tijd, dan is het risico van een bitfout in het risicogebied toch maar iets van 1 op (365 * 24 * 3600 * 10²), ofwel 1 op 3⁹?

Of maak ik hier een gedachten/rekenfout?

[Q]

De rekensom die je maakt voor geheugen geldt precies hetzelfde voor de harde schijf? Waarom zou dat anders zijn? Die stats waren over 17 maanden voor een harde schijf, dus schijven zijn nog betroubaarder dan die 1 op 1200 als je er maar een jaar naar zou kijken?

Je kunt in geheugen of op de schijf last hebben van tijdelijke of permanente fouten, dat maakt eigenlijk niet eens uit. Hoe groot is de kans dat jouw super belangrijke bestand net op die ene disk sector komt?

Als jij in je linker hand een reepje geheugen hebt en in je rechter hand een schijf, dan weet jij met de stats uit de genoemde bronnen welk ding het vaakst ellende gaat zien en welke van de twee je qua prioriteit dus het beste kunt aanpakken, wat mij betreft.

Anyway.

Als je naar een PC kijkt dan zie je dat aan alle kanten overal ECC / Parity of wat dan ook wordt toegepast op echt alles. SATA, PCIe protocol, etc.

Bij consumenten hardware kun je drie plekken aanwijzen waar het kan ontbreken of ontbreekt.

1. Regulier werkgeheugen / RAM
2. Geheugen van de netwerk kaart
3. Geheugen (buffer) van de harde schijf.

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

1 & 2 vang je af met server hardware / ECC RAM. 3 vang je niet af zonder ZFS of BTRFS. Maar uit de studie kunnen we halen dat in zijn algemeenheid de kans op silent data corruptie van harde schijven erg klein is.

Er is nog een interessant feitje: in die studie over de schijven worden de SATA disks met een SATA-to-FC connector aangesloten, die converter wordt ook als extra oorzaak van ellende gezien, weer een component extra wat voor storingen kan zorgen, maar zo'n ding heb je thuis natuurlijk er niet tussen zitten.
Daar zeggen ze ook iets over meen ik.

[vanaalten]

Q schreef op woensdag 06 januari 2016 @ 01:17:
De rekensom die je maakt voor geheugen geldt precies hetzelfde voor de harde schijf? Waarom zou dat anders zijn? Die stats waren over 17 maanden voor een harde schijf, dus schijven zijn nog betroubaarder dan die 1 op 1200 als je er maar een jaar naar zou kijken?

In geheugen heb je twee soorten fouten: bitflips door ruis en permanente fouten door hardware defecten. Die rekensom die ik maakte (met 1 op 3⁹ als uitkomst, gebaseerd op Google studie) is -volgens mij- die eerste categorie. Weet ik niet helemaal zeker, maar ik kreeg de indruk dat die Google-studie het meer heeft over bitflips dan hardware fouten. En in dat geval moet je volgens mij wel degelijk de tijd dat de data in het geheugen staat meenemen. Geheugen bitfouten als er geen belangrijke data in staat vind ik niet zo spannend.

Bij de categorie 'permanente fouten' voor geheugen weet ik even niet hoe je daar statistisch mee om moet gaan.

Permanente fouten voor harde schijven: da's volgens mij waar jij mee begon, bit rot: een bit dat magnetisch 'omvalt' en fout blijft. Dat zou dus die 1 op 1193 risico zijn, gedurende 17 maanden. Maar ik denk dat als je het eerlijker wil vergelijken, je de bestandsgrootte wellicht ook mee moet nemen (bitrot op een plek waar geen, of een onbelangrijk, bestand staat is niet van belang; plus dat we voor geheugen bitfouten enkel voor dat ene belangrijke bestand keken, dus moet je dat voor de schijf ook doen).

Plus dat je ook de bewaar-tijd mee zal moeten nemen: als een bestand vier jaar opgeslagen is heb je grotere kans op bit-rot dan als het maar een dag bewaard wordt.

En niet-permanente fouten voor harde schijven zou dan dus die 'Non-recoverable read errors per bits read: <1 in 10¹⁴' zijn waar ik mee begon: puur op het moment van uitlezen van het bestand kan je een bitflip hebben. Wil je die kans berekenen, dan moet je dus ook weten hoe vaak een bestand teruggelezen wordt.

Ofwel: voor een echt nauwkeurige kansberekening moet je meer informatie hebben over hoe de data gebruikt/bewaard wordt.

Maar, qua orde grootte denk ik op dit moment dat de kans op bit rot gedurende de bewaartijd veel groter is (die 1:1193, waar nog wat gecorrigeerd moet worden voor bestandgrootte en bewaartijd) dan de kans op geheugenfouten (mijn 1 op 3⁹, waar nog wat gecorrigeerd moet worden voor hoe lang het bestand in het geheugen staat en de grootte van het bestand).

Dus, eh, als je op basis daarvan zou moeten kiezen tussen ECC of ZFS, dan zou ECC wellicht de minder relevante zijn: (kans op bitrot) >> (kans op geheugenfouten). Denk ik. Slag om arm, disclaimer voor denkfouten en zo.

[Q]

vanaalten schreef op woensdag 06 januari 2016 @ 08:29:
[...]
Weet ik niet helemaal zeker, maar ik kreeg de indruk dat die Google-studie het meer heeft over bitflips dan hardware fouten.

Een van de bevindingen van de Google studie was juist dat tijdelijke bitflips door cosmische radiation of weet ik veel wat juist veel minder vaak voorkomen dan gedacht en dat de hardware meestal permanent brak is: bitflips vinden plaats in de zelfde defecte cellen. Er was een correlatie.

Lijkt dus veel meer op een 'bad sector' maar dan in je RAM.

Maar ik denk dat als je het eerlijker wil vergelijken, je de bestandsgrootte wellicht ook mee moet nemen (bitrot op een plek waar geen, of een onbelangrijk, bestand staat is niet van belang; plus dat we voor geheugen bitfouten enkel voor dat ene belangrijke bestand keken, dus moet je dat voor de schijf ook doen).

Ik den zelf dat dit niet de juiste manier is om er tegen aan te kijken.

Ik heb hier 1 reepje geheugen en 1 harde schijf. Gedurende een jaar, hoe groot is de kans dat ik een bitflip zie?

Met de toename van de leeftijd zal hardware onbetrouwbaarder worden, maar dat geld voor beide componenten.

Afhankelijk van het type fout in geheugen is een bit flip in geheugen in mijn beleving potentieel gevaarlijker. Een silent corrupte sector op een schijf treft 1 file op 1 schijf.

Een rotte bit in het werkgeheugen kan keer op keer 'verse' data stuk maken. Dat geldt natuurlijk ook voor een rotte sector die als scratch space voor berekeningen wordt gebruikt, maar dat vind ik wat verder gezocht.

Dat gaat een beetje in tegen het concept dat de hoeveelheid data zo belangrijk is. Het is veel meer de impact die het kan hebben. RAM zit op een plek in de keten (midden in) waar het erg veel schade kan geven.

Dat zie je vaak ook zo mooi in die zpool stats van mensen met rot werkgeheugen. Een zooi ECC errors over alle harde schijven (symptoom).

[ Voor 9% gewijzigd door Q op 06-01-2016 10:37 ]

[player-x]

Q schreef op woensdag 06 januari 2016 @ 10:34:
Met de toename van de leeftijd zal hardware onbetrouwbaarder worden, maar dat geld voor beide componenten.

Dat geld zeker niet voor geheugen, ik heb een hele berg geheugen hier liggen, teruggaande naar 256KB dimm's, en zelfs het geheugen in mijn nog steeds werkende Apple II doet het ook nog steeds.

Daar in tegen heb ik een verhuisdoos 3/4 vol met defecte HDDs, de cellen van SDRAM in tegen stelling van NAND slijten niet, ik wil niet zeggen dat cellen van SDRAM het eeuwige leven hebben, maar het is wel een van de meer betrouwbare onderdelen van je PC!

Daarnaast is nagenoeg iedereen conservatief met geheugen snelheden, waarom super snel (duur) geheugen nemen, als langzamer geheugen en meer betrouwbaar geheugen, meer dan voldoende is voor een file server.

Afhankelijk van het type fout in geheugen is een bit flip in geheugen in mijn beleving potentieel gevaarlijker. Een silent corrupte sector op een schijf treft 1 file op 1 schijf.

Ik zie geen reden waarom een bitflip gevaarlijker is dan een silent corrupte sector, eerder andersom, een bitflip is tijdelijk een bitje dat veranderd is, een corrupte sector is permanent, en spreid zich meestal ook uit.

Een rotte bit in het werkgeheugen kan keer op keer 'verse' data stuk maken. Dat geldt natuurlijk ook voor een rotte sector die als scratch space voor berekeningen wordt gebruikt, maar dat vind ik wat verder gezocht.

Een rotte bit in het werkgeheugen zorgt voor ook voor een onstabiel systeem, maar ben het met je eens dat het ernstig is, maar is daar in tegen iets dat zelden of nooit voor komt.

Dat gaat een beetje in tegen het concept dat de hoeveelheid data zo belangrijk is. Het is veel meer de impact die het kan hebben. RAM zit op een plek in de keten (midden in) waar het erg veel schade kan geven.

Niemand ontkend dat geheugen problemen niet ernstig zijn, alleen zijn de risico's zo klein dat de meeste mensen voor thuis gebruik het risico maar voor lief nemen.

Want dat is net zo iets als een relatief dure 'Hole in One' verzekering afsluit, als de prijs een weekendje in een hotel op de Veluwe is

Dat zie je vaak ook zo mooi in die zpool stats van mensen met rot werkgeheugen. Een zooi ECC errors over alle harde schijven (symptoom).

En hoe vaak komt dat voor in tegenstelling van de andere ernstige problemen die mensen hebben?

Alles dat ik lees op de forums, geeft mij nog steeds steeds meer het gevoel dat het meer een theoretische probleem is dan daadwerkelijk een echt praktijk probleem.

En de voorbeelden en theorieën die jij steeds aanbrengt kunnen mij niet van het tegen deel overtuigen, dan dat ECC te aanbevelen is voor een thuis server, maar zeker niet heel noodzakelijk.

[Q]

Het argumenteren vanuit persoonlijke anekdote vind ik niet relevant. Ik kijk liever naar de studies.

Zelf zou ik mij niet al te veel bazeren op wat een paar mensen in een forum roepen inclusief wat ik zelf schrijf, wees kritisch, zou ik zeggen en bepaal zelf wat je keuze wordt.

Met dat geheugen wat je thuis hebt waarvan je aangeeft dat het nog steeds werkt: dat zal best, maar het gebrek aan ECC maakt ook dat eventuele (tijdelijke) flips niet door jouw worden opgemerkt. En een memtest86 is maar een moment opname.

Waar je volgens mij de fout in gaat (en je bent zeker niet de enige) is dat een URE of bad sector op disk nog geen silent data corruptie is. Dat disks misschien veel vaker stuk gaan dan geheugen is niet relevant.

Echte silent data corruptie merk je niet, de disk geeft geen fouten, maar toch is je data niet goed. De kans dat dit gebeurt is enorm klein vanwege alle ECC die voor iedere 4K sector wordt opgeslagen.

In 99.999% van de gevallen faalt een disk gewoon 'veilig'. Of hij geeft je data terug, of niet, maar hij liegt niet. Een disk is behoorlijk eerlijk. RAID handelt het verder af of je verliest een file ofzo. Maar dat is het.

Regulier geheugen heeft deze protectie niet, dus het equivalent van een URE of bad sector in het geheugen is meteen gewoon data corruptie. Boom! De impact is juist meteen veel ernstiger. Je hebt tijdelijke bitflips, maar de semi-permanente bitflips komen veel vaker voor. Geheugen dat 1x een flip heeft gezien heeft een sterk verhoogde kans om er meer te zien, of zelfs dat het permanent is.

Met ECC geheugen in je systeem is je werkgeheugen pas op een vergelijkbaar of beter veiligheidsniveau als een harde schijf, qua integriteit.

De rest risico's waar ZFS dan tegen beschermt daar van kun je je sterk afvragen of dat thuis zo'n issue is.
Het beste argument voor ZFS is in deze context dat wij SATA / consumenten schijven gebruiken, die ook intern voor hun cache geen ECC gebruiken.

Maar de risico's op dit vlak zijn zo klein. De hoeveelheid cache geheugen op een disk is minuscuul.

------

Thuis is ECC helemaal niet 'noodzakelijk'.
Thuis is ZFS helemaal niet 'noodzakelijk'.

Als je thuis net zolief een Qnap of Synology had neergezet dan boeit deze discussie niet.

Geef je heel erg om data integriteit dan is ECC en ZFS wel noodzakelijk. Waar wat mij betreft de prioriteit bij de hardware ligt, het fundament.

Zoals ik tegen alle informatie aan kijk: de kans op ellende door rot werkgeheugen is groot genoeg dat je er als thuis gebruiker ook door getroffen zou kunnen worden. De risico's waar ZFS tegen beschermt zijn wat mij betreft veel meer een probleem in een enterprise setting waarin over zeer grote aantalle disks statistisch de kans op data corruptie gewoon te groot wordt.

Anekdote alert: Ik draai ZFS en ECC, tot nu toe hebben ZFS en ECC mij nog niet gered, zonde van die investering

[Verwijderd]

Zeggen jullie nu echt iets heel verschillends?

Een Qnap, Synology of ZFS systeem zonder ECC beschermt je tegen de uitval van een Harddisk. Geen van deze oplossingen beschermt je tegen silent data corruption. Voor veel mensen is dat geen probleem, een enkel bestand dat corrupt raakt is niet zo'n groot probleem, en de kans dat precies datzelfde bestand in je backup corrupt is, is erg klein.

Als je je backups goed opzet, betekent een bitflip op de bron kant, dat aan de backup kant de oude versie niet overschreven wordt. Of je backupsoftware vangt het af omdat die denkt dat het niet gewijzigd is, of je backup bewaart het origineel omdat het bestand gewijzigd is en slaat een kopie op.

ZFS biedt mijn inziens dan nog steeds voordelen over een Synology of legacy RAID oplossing, zowel in de administratie als in de kosten (omdat je juist schijven zonder TLER wil en dus goedkopere schijven kan gebruiken), maar primair zal je het gebruiken om te voorkomen dat je een restore van backup moet doen als er een schijf uitvalt. 20TB downloaden van Glacier is niet fijn! De extra zekerheid op file niveau is een leuke bonus bij thuisgebruik.

Het echte risico waar ECC tegen beschermt is dat je bewerkingen gaat uitvoeren met silent corrupted data en dat zoiets dure/ernstige gevolgen heeft, niet iets waar de meeste thuisgebruikers zich zorgen over hoeven te maken. Voor bedrijven kan dit wel cruciaal zijn dus dan ga je voor de full package. Zoals ik eerder al zei, inclusief workstations met ECC, anders is je ECC in de server ook niet nuttig om dat je een breuk in de ketting van checksums hebt.

[vanaalten]

Verwijderd schreef op woensdag 06 januari 2016 @ 17:20:
Een Qnap, Synology of ZFS systeem zonder ECC beschermt je tegen de uitval van een Harddisk. Geen van deze oplossingen beschermt je tegen silent data corruption.

Eh, jawel, dat doet ZFS nou toch juist wel? Checksums over blokken en dergelijke, parity data om bij corruptie te kunnen herstellen?

Als je je backups goed opzet, betekent een bitflip op de bron kant, dat aan de backup kant de oude versie niet overschreven wordt. Of je backupsoftware vangt het af omdat die denkt dat het niet gewijzigd is, of je backup bewaart het origineel omdat het bestand gewijzigd is en slaat een kopie op.

Mwah, dubieuze redenering. Veel backupsystemen bewaren inderdaad oude versies, maar voor beperkte tijd. Mijn backup naar Amazon werkt in elk geval op die manier - zodat ALS m'n data door ransomware spontaan encrypted is, ik nog een of meerdere versies terug kan. Maar als een bestand dat ik eens per jaar of zo bekijk door silent corruption kapot gaat, dan zal de backup niet helpen: na een jaar lang een corrupte versie backuppen zal de goede er niet meer zijn.

ZFS biedt mijn inziens dan nog steeds voordelen over een Synology of legacy RAID oplossing, zowel in de administratie als in de kosten (omdat je juist schijven zonder TLER wil en dus goedkopere schijven kan gebruiken), maar primair zal je het gebruiken om te voorkomen dat je een restore van backup moet doen als er een schijf uitvalt. 20TB downloaden van Glacier is niet fijn! De extra zekerheid op file niveau is een leuke bonus bij thuisgebruik.

Nou, nee dus: het beschermt tegen silent data corruption, da's ook wel belangrijk. En met een mirror-situatie als bonus ook nog eens weinig downtijd. En als het systeem geroosterd wordt door bliksem, dan heb ik nog de backup.

En nee, ik heb geen ECC geheugen want:
1) wilde het betaalbaar houden
2) de kans op bitfouten door geheugen schat ik niet zo hoog in, want het staat er in principe maar heel kort. in.
(toegegeven, '2' bedenk ik pas sinds ik dit topic volg - '1' was het belangrijkste)

Het echte risico waar ECC tegen beschermt is dat je bewerkingen gaat uitvoeren met silent corrupted data en dat zoiets dure/ernstige gevolgen heeft, niet iets waar de meeste thuisgebruikers zich zorgen over hoeven te maken. Voor bedrijven kan dit wel cruciaal zijn dus dan ga je voor de full package.

Dit topic is voor een zelfbouw NAS en ik denk dat daarbij er sowieso niet veel bewerkingen in het geheugen plaatsvinden: data komt binnen via het netwerk, staat even in het geheugen en wordt snel doorgesluisd naar de harddisks. Ik vermoed dat de tijd dat het vatbaar is voor bitflips in het geheugen niet zo groot is.

[MadEgg]

Ik ben bezig met een NAS / HTPC projectje voor thuis. Uit budgetairre overwegingen wil ik die vooralsnog in één systeem vatten, en denk eraan om dit te gaan doen met Debian icm ZFS. Tegen het einde van dit jaar wil ik er nog een extra server bijplaatsen die puur als NAS moet gaan functioneren, zodat de HTPC gewoon uitkan als we hem niet gebruiken. Deze server zal dan ook uitgerust worden met ECC RAM, en ik vermoed dat deze FreeNAS zal gaan draaien.

De huidige hardware hiervoor (nieuw aangeschaft Intel Skylake setje) beschikt niet over ECC RAM. Ik zit nu te twijfelen over of ik hier nu ZFS kan gaan toepassen, met dank aan de spookverhalen over non-ECC RAM. Ik snap de risico's, heb natuurlijk backups van mijn data, maar zit niet te wachten op een corrupte zpool. Wat mij het meeste tegenstaat is de opmerking van de beruchte Cyberjock die stelt dat in tegenstelling tot 'legacy' bestandssystemen waarbij het risico tot corruptie met name optreedt bij schrijfoperaties, bij ZFS dit risico ook optreedt bij elke leesoperatie, en met name de aangeraden periodieke scrubs.

Als ik de NAS/HTPC gewoon gebruik met Ext4, dm-raid en dm-crypt ben ik er zeker van dat er niet explicitiet correcte data kapot gemaakt wordt als het RAM zich misdraagt. Natuurlijk ben je er dan net zo goed niet zeker van dat er geen stille corruptie optreedt, maar het risico daarop schat ik vrij klein op basis van mijn ervaringen uit het verleden. Bovendien zien er legio methoden om een Ext4-bestandssysteem te rescuen terwijl er steeds benadrukt wordt dat die niet aanwezig zijn voor ZFS. Vanzelfsprekend ga ik eerst het nieuwe systeem uitgebreid met Memtest86 testen en ik ben ook van plan om er een dagje Prime95 op te draaien om te verifiëren dat ik in ieder geval begin met goede hardware.

Redenen om nu wél voor ZFS te gaan zijn natuurlijk dat ik er alvast mee wil experimenteren en bovendien is het dan lekker makkelijk om de data over te dragen naar de nieuwe NAS zodra ik die aangeschaft heb mbv zfs send, naar ik begrepen heb

Wat is nu wijsheid? Ik heb de discussie hier en die in Het grote ZFS topic doorgelezen, maar zie er eigenlijk nergens mijn grootste angst aangehaald: dat ZFS ook data zou kunnen corrumperen bij kapot RAM tijdens een lees-operatie. Hoe denken jullie hierover?

CiPHER veelvuldig genoemde experiment met kapot RAM stelt mij ietwat gerust, maar bij een dergelijk experiment heb je er natuurlijk geen invloed op welke corruptie waar optreedt dus het blijft de vraag of je alle mogelijke scenario's wel afgevangen hebt daarmee.

[RedShift]

Met de werkuren in deze thread verzameld kon al lang ECC geheugen/mobo/CPU gekocht worden... De kost van ECC materiaal is zodanig laag dat er over discussiëren meer kost...

[begintmeta]

offtopic:
Wat had met de werkuren die in GoT zitten wel niet voor moois kunnen worden gemaakt...

[MadEgg]

RedShift schreef op woensdag 06 januari 2016 @ 19:21:
Met de werkuren in deze thread verzameld kon al lang ECC geheugen/mobo/CPU gekocht worden... De kost van ECC materiaal is zodanig laag dat er over discussiëren meer kost...

Als Intel niet hardnekkig ECC uit hun consumenten-chipsets hield wel ja. De processor ondersteunt wel ECC, maar het moederbord / de chipset niet. Het goedkoopste moederbord wat dat wel doet en deze processor ondersteund is 2,5 keer zo duur (120 euro duurder om precies te zijn). Daar komt dan ook nog het geheugen bij wat ook 50 euro meer zou kosten voor dezelfde hoeveelheid. Daarnaast wil ik hem als HTPC gebruiken dus een HDMI-uitgang is essentieel. Aangezien die ontbreekt op het server-moederbord zou er dan ook nog een videokaart a minstens 30 euro bijgeplaatst moeten worden. Helaas betaalt niemand mij 200 euro om deze threads niét door te lezen, in mijn vrije tijd, dus jouw argument gaat niet helemaal op

[player-x]

RedShift schreef op woensdag 06 januari 2016 @ 19:21:
Met de werkuren in deze thread verzameld kon al lang ECC geheugen/mobo/CPU gekocht worden... De kost van ECC materiaal is zodanig laag dat er over discussiëren meer kost...

Hmmm........

Bestaande hardware hergebruiken?

Of nieuwe kopen!

#	Product	Prijs	Subtotaal
1	Intel Pentium G4400 Boxed	€ 61,-	€ 61,-
1	Asus P10S-I	€ 195,90	€ 195,90
1	Crucial CT2K4G4WFS8213	€ 93,09	€ 93,09
Bekijk collectie Importeer producten		Totaal	€ 349,99

Hmmmmm, als je 350 euro extra + verzendkosten geen echte goede reden vind dan weet ik het niet echt hoor.

[Verwijderd]

vanaalten schreef op woensdag 06 januari 2016 @ 18:23:
[...]

Eh, jawel, dat doet ZFS nou toch juist wel? Checksums over blokken en dergelijke, parity data om bij corruptie te kunnen herstellen?
[...]

Mwah, dubieuze redenering. Veel backupsystemen bewaren inderdaad oude versies, maar voor beperkte tijd. Mijn backup naar Amazon werkt in elk geval op die manier - zodat ALS m'n data door ransomware spontaan encrypted is, ik nog een of meerdere versies terug kan. Maar als een bestand dat ik eens per jaar of zo bekijk door silent corruption kapot gaat, dan zal de backup niet helpen: na een jaar lang een corrupte versie backuppen zal de goede er niet meer zijn.

[...]
Nou, nee dus: het beschermt tegen silent data corruption, da's ook wel belangrijk. En met een mirror-situatie als bonus ook nog eens weinig downtijd. En als het systeem geroosterd wordt door bliksem, dan heb ik nog de backup.

En nee, ik heb geen ECC geheugen want:
1) wilde het betaalbaar houden
2) de kans op bitfouten door geheugen schat ik niet zo hoog in, want het staat er in principe maar heel kort. in.
(toegegeven, '2' bedenk ik pas sinds ik dit topic volg - '1' was het belangrijkste)

[...]

Dit topic is voor een zelfbouw NAS en ik denk dat daarbij er sowieso niet veel bewerkingen in het geheugen plaatsvinden: data komt binnen via het netwerk, staat even in het geheugen en wordt snel doorgesluisd naar de harddisks. Ik vermoed dat de tijd dat het vatbaar is voor bitflips in het geheugen niet zo groot is.

Alleen silent corruption door de disks, als het bij het schrijven door een memory flip fout gaat heb je silent data corruption en weet je het niet.
De enige effectieve methode tegen silent data corruption is checksumming en ECC.

[Q]

Verwijderd schreef op woensdag 06 januari 2016 @ 17:20:
Voor bedrijven kan dit wel cruciaal zijn dus dan ga je voor de full package. Zoals ik eerder al zei, inclusief workstations met ECC, anders is je ECC in de server ook niet nuttig om dat je een breuk in de ketting van checksums hebt.

Misschien moet je dan toch even alle bedrijven opbellen en dat uitleggen want iedereen draait met ECC op de servers (je kunt geen servers zonder kopen) en alle medewerkers 99.99% draaien op laptops of desktops zonder ECC geheugen.

MadEgg schreef op woensdag 06 januari 2016 @ 19:02:
IWat mij het meeste tegenstaat is de opmerking van de beruchte Cyberjock die stelt dat in tegenstelling tot 'legacy' bestandssystemen waarbij het risico tot corruptie met name optreedt bij schrijfoperaties, bij ZFS dit risico ook optreedt bij elke leesoperatie, en met name de aangeraden periodieke scrubs.

Wat hij schetst geldt eigenlijk voor ieder file system. Met rot geheugen is iedere schrijf actie naar schijf een potentiele data corrumperende actie en dat kan je hele file system zelf naar zijn grootje helpen.

Is niet ZFS-specifiek.

ZFS heeft geeh chkdsk/fsck dus dan is het gewoon over. Bij legacy file systems kun je door die tools nog wel eens gered worden.

Als ik de NAS/HTPC gewoon gebruik met Ext4, dm-raid en dm-crypt ben ik er zeker van dat er niet explicitiet correcte data kapot gemaakt wordt als het RAM zich misdraagt.

Encryptie met rot werkgeheugen is een extra goed recept voor data verlies denk ik.

Natuurlijk ben je er dan net zo goed niet zeker van dat er geen stille corruptie optreedt, maar het risico daarop schat ik vrij klein op basis van mijn ervaringen uit het verleden.

Conceptueel helpt encryptie je niets behalve dan dat decyptie niet goed lukt en de data kan even goed verkloot zijn.

Bovendien zien er legio methoden om een Ext4-bestandssysteem te rescuen terwijl er steeds benadrukt wordt dat die niet aanwezig zijn voor ZFS. Vanzelfsprekend ga ik eerst het nieuwe systeem uitgebreid met Memtest86 testen en ik ben ook van plan om er een dagje Prime95 op te draaien om te verifiëren dat ik in ieder geval begin met goede hardware.

Het is beter dan niets maar daar is dan ook alles mee gezegd.

Wat is nu wijsheid? Ik heb de discussie hier en die in Het grote ZFS topic doorgelezen, maar zie er eigenlijk nergens mijn grootste angst aangehaald: dat ZFS ook data zou kunnen corrumperen bij kapot RAM tijdens een lees-operatie. Hoe denken jullie hierover?

Goede data op disk zal niet snel corrupt worden aangeleverd aan een app door ZFS's checksum controle. De kans dat je door rot geheugen dat mee maakt is denk ik niet zo groot.

CiPHER veelvuldig genoemde experiment met kapot RAM stelt mij ietwat gerust, maar bij een dergelijk experiment heb je er natuurlijk geen invloed op welke corruptie waar optreedt dus het blijft de vraag of je alle mogelijke scenario's wel afgevangen hebt daarmee.

Je geeft zelf het antwoord, ik zou weinig afleiden uit een ongecontroleerd experiment. Ik zie zelf met rot geheugen vooral risico met het wegschrijven van data.

-----------

Als je er voor kiest om gewoon je huidige hardware te recyclen en zonder ECC maar met ZFS te draaien, prima, lijkt me redelijk. Draai je gewoon zonder ECC en met EXT4 met/zonder encryptie, ook redelijk. De kans is gewoon heel erg groot dat het goed gaat. ECC/ZFS is beter, maar kies maar. Server hardware kost geld, heeft extra voor/nadelen. Maak een eigen afweging op basis van wat het voor jou waard is.

[ Voor 72% gewijzigd door Q op 06-01-2016 21:51 ]

[Verwijderd]

Q schreef op woensdag 06 januari 2016 @ 21:24:
[...]


Misschien moet je dan toch even alle bedrijven opbellen en dat uitleggen want iedereen draait met ECC op de servers (je kunt geen servers zonder kopen) en alle medewerkers 99.99% draaien op laptops of desktops zonder ECC geheugen.

Tja, dan zijn ze dus niet benauwd voor bitflips in de data bij gebruik blijkbaar.

Ik weet wel dat de modellen waar ik mee werk aleen op hardware met ECC geheugen loopt. Beetje dom om je druk te maken over geheugen corruptie op de server en dan volkomen aan WS kant te negeren.

ECC is geen alternatief voor goede backups.

Overigens Een goede backup bewaar je lang.

[ Voor 6% gewijzigd door Verwijderd op 06-01-2016 21:32 ]

[Q]

Verwijderd schreef op woensdag 06 januari 2016 @ 21:28:
[...]

Tja, dan zijn ze dus niet benauwd voor bitflips in de data bij gebruik blijkbaar.

We maken ons druk over ECC in laptops en desktops en dan voert een collega ergens 10.000 in plaats van 1.000 in. Waar liggen de risico's en wat is eigenlijk het verschil

De context hier is dat een desktop/laptop puur een invoer scherm is en geen berekeningen doet.

Ik weet wel dat de modellen waar ik mee werk aleen op hardware met ECC geheugen loopt. Beetje dom om je druk te maken over geheugen corruptie op de server en dan volkomen aan WS kant te negeren.

Precies, als je berekeningen toevertrouwd aan een werkstation dan wil je geen bitflips, zal in jouw wereld ook wel onderdeel van de cultuur zijn dat mensen hier rekening mee houden. Afhankelijk van de software wordt het mogelijk ook vereist of expliciet geadviseerd, kan ik mij voorstellen.

[ Voor 43% gewijzigd door Q op 06-01-2016 21:50 ]

[Verwijderd]

Q schreef op woensdag 06 januari 2016 @ 21:47:
[...]


We maken ons druk over ECC in laptops en desktops en dan voert een collega ergens 10.000 in plaats van 1.000 in. Waar liggen de risico's en wat is eigenlijk het verschil

Het verschil? Als je PC een Bestralings machine aanstuurt voor kankerbestrijding. Als je dat verwerkt van een kerncentrale voor de regulering, ik noem maar wat.

Maar inderdaad in administraties is een invoer fout waarschijnlijker. Overigens gebruikt men in die omgeving nooit client side ECC, maar ik zie daar ook de absolute noodzaak voor serverside ECC niet. In die branche gooit men toch nooit backups weg

[MadEgg]

Q schreef op woensdag 06 januari 2016 @ 21:24:
Als je er voor kiest om gewoon je huidige hardware te recyclen en zonder ECC maar met ZFS te draaien, prima, lijkt me redelijk. Draai je gewoon zonder ECC en met EXT4 met/zonder encryptie, ook redelijk. De kans is gewoon heel erg groot dat het goed gaat. ECC/ZFS is beter, maar kies maar. Server hardware kost geld, heeft extra voor/nadelen. Maak een eigen afweging op basis van wat het voor jou waard is.

Ik recycle geen hardware, dit is een twee-fase-project. In de eerste fase heb ik hardware aangeschaft die zowel als HTPC als NAS (min of meer dan) geschikt is. Zolang het duurt zal deze dus ook als NAS dienst gaan doen. Na 6 tot 9 maanden zal deze functie overgedragen worden aan een dedicated NAS met ECC geheugen, maar dat duurt dus nog wel even. Bedankt voor het advies. Als het niet zo'n vaart loopt dan vertrouw ik die maanden wel op mijn externe backup mocht het echt fout gaan, maar die kans is dus niet zo groot als Cyberjock je wil doen geloven, begrijp ik.

[player-x]

Verwijderd schreef op woensdag 06 januari 2016 @ 21:28:
Ik weet wel dat de modellen waar ik mee werk aleen op hardware met ECC geheugen loopt. Beetje dom om je druk te maken over geheugen corruptie op de server en dan volkomen aan WS kant te negeren.

Alle echte workstations maken ook gebruik van ECC, client PC is een heel ander verhaal.

Maar het heeft zeker wel nut om zelfs alleen je server met ECC uit te voeren, een client die faalt een klein probleem is, als een server die faalt zijn de problemen veel groter, kan zelfs behoorlijk catastrofaal zijn!

Een server uitvoeren met ECC kost 150~300 euro extra, 100 client PC uitvoeren met ECC 15.000 euro, de rekensom is dan snel gemaakt.

Thuis economics werkt natuurlijk heel anders, helaas ziet niet iedereen dat helemaal in.

[Q]

Verwijderd schreef op woensdag 06 januari 2016 @ 21:51:
Maar inderdaad in administraties is een invoer fout waarschijnlijker. Overigens gebruikt men in die omgeving nooit client side ECC, maar ik zie daar ook de absolute noodzaak voor serverside ECC niet. In die branche gooit men toch nooit backups weg

Aan corrupte backups heb je niets, en hoe weet je wanneer corruptie begon?
Beschikbaarheid en data integriteit boeit juist centraal veel meer. Erg klote als 100 man niet kan werken omdat je vmware data store corrupt raakte ofzo.

MadEgg schreef op woensdag 06 januari 2016 @ 22:26:
[...]


Ik recycle geen hardware, dit is een twee-fase-project. In de eerste fase heb ik hardware aangeschaft die zowel als HTPC als NAS (min of meer dan) geschikt is. Zolang het duurt zal deze dus ook als NAS dienst gaan doen. Na 6 tot 9 maanden zal deze functie overgedragen worden aan een dedicated NAS met ECC geheugen, maar dat duurt dus nog wel even. Bedankt voor het advies. Als het niet zo'n vaart loopt dan vertrouw ik die maanden wel op mijn externe backup mocht het echt fout gaan, maar die kans is dus niet zo groot als Cyberjock je wil doen geloven, begrijp ik.

Ik denk niet dat je 'onveiliger' bezig bent dan iemand die een Synology of Qnap draait. Afhankelijk van hoeveel disks je in je NAS gaat stoppen kun je het laatste linkje volgen in mijn signature.

[ Voor 42% gewijzigd door Q op 07-01-2016 01:07 ]

[MadEgg]

Q schreef op donderdag 07 januari 2016 @ 01:00:
[...]
Ik denk niet dat je 'onveiliger' bezig bent dan iemand die een Synology of Qnap draait. Afhankelijk van hoeveel disks je in je NAS gaat stoppen kun je het laatste linkje volgen in mijn signature.

Ik kom van een gebrickte Netgear ReadyNAS eigenlijk, maar vermoedelijk heeft die ook geen ECC RAM. Ook geen ZFS for that matter.

De HP Proliant Microserver's zijn inderdaad zeer leuk en gunstig geprijsd maar ik ben toch wel een dermate grote nerd/tweaker dat ik het liever zelf bouw

[Q]

MadEgg schreef op donderdag 07 januari 2016 @ 11:43:
De HP Proliant Microserver's zijn inderdaad zeer leuk en gunstig geprijsd maar ik ben toch wel een dermate grote nerd/tweaker dat ik het liever zelf bouw

Je hebt helemaal gelijk als je dat leuk vindt. Zo'n Microserver biedt weinig uitdaging

[Verwijderd]

@player-x
Ik zopu als bedrijf altijd voor ECC kiezen, simpelweg omdat dat de kosten niet zijn. Dat wil niet zeggen dat het zelfs voor bedrijven altijd noodzakelijk is. Zoals eerder al aangegeven, er gaan meer bestanden verloren door domme user acties dan door bit-rot.

Voor opslag van correspondentie (e-mails, word) en dergelijke is het meestal niet zo kritisch een bit flip heeft niet zo veel gevolgen. Een storage server die helemaal plat gaat is ernstiger.

Je wil niet weten hoeveel bedrijven op Synologies draaien uit de plus serie of goedkoper. Die hebben geen van allen ECC en ook geen checksumming.

Diezelfde bedrijven kunnen het daarom ook gewoon af met laptops en pcs zonder ECC geheugen, het boet gewoon niet. Als je server faalt switch je naar de backup server, als je bestand onleesbaar is ben je een uurtje werk kwijt. Het is maar zo...

Het wordt een ander verhaal als je grote data bestanden hebt, waar je analyses op uitvoert en waar kritische handelingen of investeringen op worden gebaseerd. Of wanneer je data opslag aanbied aan derden en daar garanties op afgeeft. In beide gevallen dus ECC geheugen op de server en ook op de machines waarop je de analyses uitvoert.

[Q]

Het voordeel van veel kleine MKB bedrijven is dat het vaak om zo weinig data gaat dat je altijd wel weer snel de boel hebt opgetuigd. Voor grotere toko's wordt dat een ander verhaal.

Ik heb notabene zelf een aantal maanden geleden nog live een storage controller door een HP engineer laten omwisselen van onze productie SAN omdat we ECC errors kregen van dat ding.

[ Voor 41% gewijzigd door Q op 07-01-2016 17:01 ]

[Verwijderd]

Er zijn meer MKB ondernemingen dan grotere toko's, er is dus wel degelijk een grote markt voor storage oplossingen die geen gebruik maken van checksumming en ECC, maar toch zakelijke oplossingen zijn.

Mijn punt is, geen ECC is niet per definitie 'fout' Ondanks dat wel ECC te alle tijden beter is. Het is een kosten/baten afweging die ook zakelijk vaak in het nadeel van ECC uitvalt.

[player-x]

kevinl schreef op vrijdag 15 juli 2016 @ 09:33:
Voor ZFS moet je toch ECC geheugen nemen?

Nee hoor ZFS draait prima zonder, het is wel wenselijk, maar het kost ook extra geld (+/- €50 tot €150 extra voor zelfbouw), de HP Proliant MicroServer Gen8 G1610T is een uitzondering, maar de meningen verschillen over de absolute noodzaak voor thuis gebruik.

Ik ben van het kamp, ja het is wenselijk, maar als het niet in het budget zit, ben je nog steeds beter af met ZFS dan met bv NTSF (win) of ext4 (Linux).

Q schreef op vrijdag 15 juli 2016 @ 09:40:
Nee het kan prima zonder, het zal werken.
Maar als je toch geen ECC doet dan maakt wel of geen ZFS ook niet zo erg uit.

Ik weet dat je er anders over denkt, maar voor mij is het zo iets als, "Ehhhh heb toch geen airbags, Oooo dan heb ik ook geen auto gordels nodig".

Ja beide zijn wenselijk, maar imho als je de een niet hebt, wil nog niet zeggen dat je geen baat hebt bij de ander!

[ Voor 7% gewijzigd door player-x op 16-07-2016 20:55 ]

[Q]

player-x schreef op zaterdag 16 juli 2016 @ 20:50:
Ik weet dat je er anders over denkt, maar voor mij is het zo iets als, "Ehhhh heb toch geen airbags, Oooo dan heb ik ook geen auto gordels nodig".

Ja beide zijn wenselijk, maar imho als je de een niet hebt, wil nog niet zeggen dat je geen baat hebt bij de ander!

Het probleem van analogieën is dat ze vaak de essentie van het probleem niet vatten. Wij kunnen nu gaan soebatten over waar de autogordels en de airbags voor staan (ik vind ECC en dan ZFS) maar dat is eigenlijk het punt niet.

De kans op een bitflip in ram thuis is gewoon heel klein. Maar de kans dat je ooit *silent* data corruptie mee maakt ook. Het gaat om relatief kleine risicos.

Beide risico's hebben een bepaalde kans. Als je die kansen aan elkaar gelijk stelt en je besluit om een van die kansen te accepteren (dus je doet alsof de kans nul is), dan is het volkomen rationeel om ook de andere kans te accepteren.

Als je risico A met een kans van 0.01% accepteert, waarom dan ook niet risico B met een kans van 0.01%? Het zijn losstaande risico's ze zijn niet afhankelijk van elkaar.

Je accepteert dus een orde van grootte van risico's.

Je besluit blijkbaar dat risico's beneden de 0.1% je niet gaat afdekken, die accepteer je en daar ga je dus geen kosten aan besteden (geld/tijd/moeite).

Dan kun je beiden dus wegstrepen. Een risico dat een schijf sterft is mogelijk 3% dus daar 'investeer' je wel in bescherming tegen dat risico.

Uiteraard kun je ook weer gaan soebatten over hoe groot de kans is op bitflips in ram of op disk, maar dat is het punt missen en ik denk dat disks hier beter uit de bus komen dan geheugen.

[ Voor 5% gewijzigd door Q op 17-07-2016 01:01 ]

[player-x]

Q schreef op zondag 17 juli 2016 @ 01:00:
Beide risico's hebben een bepaalde kans. Als je die kansen aan elkaar gelijk stelt en je besluit om een van die kansen te accepteren (dus je doet alsof de kans nul is), dan is het volkomen rationeel om ook de andere kans te accepteren.

Nee zoals ik al eerder heb gezegd, ik kijk gewoon heel anders tegen het probleem aan dan jij, van een imho veel praktischer oogpunt, special voor de op budget DIY NAS thuis bouwer.

Voor mij is het simpel, is de kans op problemen met ZFS zonder ECC kleiner of groter dan met NTFS of ext4 (ook zonder ECC), zover ik kan zien ben je nog veel steeds beter af met ZFS dan met NTFS of ext4 als het gaat om zowel silent of catastrofale file systeem problemen.

Dat neemt niet weg dat ik zelf ook voor ECC heb gekozen, voor systemen die met ZFS of BtrFS werken, maar ja dat zijn natuurlijk ook wel systemen met minimaal 10 disks, dan is de extra investering die je dan moet doen in verhouding ook veel minder.

[ Voor 4% gewijzigd door player-x op 17-07-2016 06:40 ]

[Q]

player-x schreef op zondag 17 juli 2016 @ 06:28:
[...]

Nee zoals ik al eerder heb gezegd, ik kijk gewoon heel anders tegen het probleem aan dan jij, van een imho veel praktischer oogpunt, special voor de op budget DIY NAS thuis bouwer.

Als je bedoelt met 'praktischer' dat je gewoon geen oog hebt voor kans en context, dan geef ik je gelijk. Dan maak je het jezelf een stuk simpeler, maar laten we niet doen alsof dat dus ook meteen tot een goed advies leidt.

Voor mij is het simpel, is de kans op problemen met ZFS zonder ECC kleiner of groter dan met NTFS of ext4 (ook zonder ECC), zover ik kan zien ben je nog veel steeds beter af met ZFS dan met NTFS of ext4 als het gaat om zowel silent of catastrofale file systeem problemen.

Maar zo simpel als jij het hier beschrijft is het niet.

Als 'beter' betekent dat je een kans wegneemt van 0.001% dan kan iemand zeggen: waarom moet ik me nu druk gaan maken om ZFS, waar ik weinig kaas van heb gegeten en bovendien last heeft van het nadeel dat je VDEVs niet kunt uitbreiden voor een kans die vrijwel te verwaarlozen is?

Het is niet zo straightforward, ZFS beschermt tegen silent data corruptie *DUS* is de betere optie voor een DIY NAS bouwer. Dat is onzin, want dan hou je helemaal geen rekening met alle andere factoren, omstandigheden, wensen en eisen.

Je maakt je keuzes altijd in een context en als je die context niet mee weegt dan geef je in mijn ogen slecht advies.

Een eerlijke voorstelling van zaken is dat ZFS inderdaad tegen silent data corruptie beschermt en dat de andere file systems dat niet doen. Maar omdat de kans op silent data corruptie zo klein is, zou dit niet de doorslaggevende reden moeten zijn in je keuze voor een file system of voor je NAS oplossing.

Zeker niet als je besluit om geen ECC RAM toe te passen want dan geef je toch al aan dat je niet zoveel geeft om deze kleine risico's en dat je bereid bent om die te accepteren.

Dat geeft mensen ook meer ruimte om een keuze te maken die beter past bij hun eigen situatie, in plaats van dat ze zich koste-wat-het-kost-want-zfs-is-veiliger in een oplossing schoenlepelen die ze niet de baas zijn.

[ Voor 11% gewijzigd door Q op 17-07-2016 13:16 ]

[IceTeaGX]

Het gebruik van ZFS is wel gratis. (tegenover een windows is een freenas zelfs goedkoper)
Dit tegenover het gebruik van ECC waar een meerkost aan zit.

[Q]

player-x schreef op zondag 17 juli 2016 @ 15:09:
[...]

Om een ook voor jouw bekend artikel aan te halen, silent corruption komt steeds vaker voor, vooral nu drives steeds groter worden.

Het artikel bevat geen relevante statistieken over de kans op silent data corruptie dus jouw link voegt niets toe aan de discussie en steunt je positie niet.

Ik heb trouwens een link naar Intel geplaatst die met mogelijk (partijdige) getallen komt aanzetten in de 'kroeg'.
Intel gebruikt de getallen om haar SSDs te promoten dus ik neem ze met een korrel zout.

Maar nog steeds is de kans erg klein.

De kans op silent data corruptie in harde schijven is een stuk kleiner dan een bit flip in ram, als je deze stats van Intel zou geloven.

Dus als je ECC al niet nodig vind, waarom dan wel ZFS?

[ Voor 11% gewijzigd door Q op 17-07-2016 18:35 ]

[dcm360]

Q schreef op zondag 17 juli 2016 @ 18:32:
[...]


Het artikel bevat geen relevante statistieken over de kans op silent data corruptie dus jouw link voegt niets toe aan de discussie en steunt je positie niet.

Ik heb trouwens een link naar Intel geplaatst die met mogelijk (partijdige) getallen komt aanzetten in de 'kroeg'.
Intel gebruikt de getallen om haar SSDs te promoten dus ik neem ze met een korrel zout.

Maar nog steeds is de kans erg klein.

De kans op silent data corruptie in harde schijven is een stuk kleiner dan een bit flip in ram, als je deze stats van Intel zou geloven.

Dus als je ECC al niet nodig vind, waarom dan wel ZFS?

ECC lost een probleem op, ZFS lost een (ander) probleem op. ECC heeft een meerprijs*, ZFS niet**. Het is dus verleidelijk om met de goedkoopste (gratis) oplossing alsnog 1 van de 2 problemen weg te nemen, ook al blijkt het andere probleem groter te zijn.

* Waarbij die meerprijs best wel meevalt. Tenminste, ik vind dat een paar tientjes nog wel valt te overzien op de totale kosten van een NAS of server.

** ZFS is weliswaar gratis, maar er zit een leercurve aan, dus in die zin betaal je er aan door er meer tijd in te moeten steken. Ook biedt ZFS bepaalde voordelen van andere oplossingen niet, maar dat is geen uniek pijnpunt van ZFS (het voor mij ideale FS bestaat nu niet).

[Q]

dcm360 schreef op zondag 17 juli 2016 @ 18:55:
[...]

ECC lost een probleem op, ZFS lost een (ander) probleem op. ECC heeft een meerprijs*, ZFS niet**. Het is dus verleidelijk om met de goedkoopste (gratis) oplossing alsnog 1 van de 2 problemen weg te nemen, ook al blijkt het andere probleem groter te zijn.

Ik begrijp de redenatie, maar ze is niet rationeel. Ik weet dat zo'n uitspraak altijd werkt als een rode lap op een stier. Maar ik kan het niet anders zeggen.

Het is niet logisch om je niet in te dekken tegen een probleem met een kans van 1 op 1000 maar wel tegen een probleem met een kans van 1 op 10.000. Hoe 'gratis' dat 2e probleem met een kans van 1 op 10.000 mag zijn.

Als je een risico accepteert van 1 op 1000, dan zeg je feitelijk: ik ga er vanuit dat een incident met een kans van 1 op 1000 mij nooit zal raken.

Als je denkt dat een probleem met een kans van 1 op 1000 je nooit zal raken, dan denk ik dat je ook zult aan nemen dat een probleem met een kans van 1 op 10.000 je nooit zal raken.

Stel nu dat je de risico's van ECC en ZFS gelijk trekt naar 1 op 1000. En je accepteert het risico van ECC dus die nemen we van tafel. Door dan toch met ZFS aan de slag te gaan, accepteer je een additioneel risico van 1 op 1000 niet maar dat risico lijkt me te verwaarlozen als je ook ECC accepteert.

Het is dan rationeler om voor ZFS te gaan omdat je toch geen probleem hebt met de 'hidden cost' en dat features als compressie, zfs send en snapshots je ook erg aan staan. Heb je daar niets mee dan is er geen persoon over boord als je niet voor ZFS kiest.

[dcm360]

Q schreef op zondag 17 juli 2016 @ 21:53:
[...]


Ik begrijp de redenatie, maar ze is niet rationeel. Ik weet dat zo'n uitspraak altijd werkt als een rode lap op een stier. Maar ik kan het niet anders zeggen.

Het is niet logisch om je niet in te dekken tegen een probleem met een kans van 1 op 1000 maar wel tegen een probleem met een kans van 1 op 10.000. Hoe 'gratis' dat 2e probleem met een kans van 1 op 10.000 mag zijn.

Als je een risico accepteert van 1 op 1000, dan zeg je feitelijk: ik ga er vanuit dat een incident met een kans van 1 op 1000 mij nooit zal raken.

Als je denkt dat een probleem met een kans van 1 op 1000 je nooit zal raken, dan denk ik dat je ook zult aan nemen dat een probleem met een kans van 1 op 10.000 je nooit zal raken.

Stel nu dat je de risico's van ECC en ZFS gelijk trekt naar 1 op 1000. En je accepteert het risico van ECC dus die nemen we van tafel. Door dan toch met ZFS aan de slag te gaan, accepteer je een additioneel risico van 1 op 1000 niet maar dat risico lijkt me te verwaarlozen als je ook ECC accepteert.

Het is dan rationeler om voor ZFS te gaan omdat je toch geen probleem hebt met de 'hidden cost' en dat features als compressie, zfs send en snapshots je ook erg aan staan. Heb je daar niets mee dan is er geen persoon over boord als je niet voor ZFS kiest.

Als het afhankelijke problemen zouden zijn, dan zou ik hier inderdaad in meegaan. Dat zijn ze echter niet, dus doe je er beter aan om de problemen onafhankelijk van elkaar te bekijken. Ook loop je voorbij aan de impact van de problemen, die is namelijk ook niet hetzelfde. Het eerste geïllustreerd met een verhaaltje:

Je koopt een server. Je weet dat de bedrading die je gaat gebruiken wat goedkoop is en in de fik kan vliegen, je schat de kans 1 op 1000 dat dit gebeurt. De oplossing is geld uitgeven aan duurdere kabels.

Vervolgens moet je bedenken waar je de server neerzet. Je hebt een prima ruimte in de kelder, echter kan die overstromen met een kans van 1 op 10 000. De oplossing is om met als enige prijs een beetje moeite de server wat trappen op te tillen naar de eerste verdieping, waar de server ook prima kan staan maar het overstromingsgevaar niet aanwezig is.

Je besluit geen geld uit te geven aan duurdere kabels. Zet je de server neer in de kelder?

[Q]

dcm360 schreef op zondag 17 juli 2016 @ 23:57:

Zet je de server in de kelder neer?

Ik zou geen moeite hebben om gezien je voorbeeld de server in de kelder te plaatsen.

Het is pas rationeel om de kleine risico's af te dekken als je eerst de grote risico's afdekt.
Dit is waar het om gaat.

Het is irrationeel om je gedrag aan te passen / te laten leiden op basis van kleine risico's terwijl je grotere risico's accepteerd.

[ Voor 71% gewijzigd door Q op 18-07-2016 10:57 ]

[dcm360]

Q schreef op maandag 18 juli 2016 @ 10:55:
[...]


Ik zou geen moeite hebben om gezien je voorbeeld de server in de kelder te plaatsen.

Dat wat wel wat ik verwachtte Het voorbeeld gaat echter nog verder:

Na een tijdje bedenk je dat je toch wel betere kabels wilt hebben, dus je schaft die aan (oftewel, je plaatst ECC geheugen in de vergelijking). De server staat nog steeds in de kelder, en nu kost het meer moeite of misschien wel geld om de server naar de eerste verdieping te verplaatsen omdat in de tussentijd het netwerk veranderd is (een wellicht niet heel erg sterke vergelijking met: er staat data op de schijven, je kan er nu niet zomaar ZFS op zetten). Had je niet beter om mee te beginnen de server op de eerste verdieping moeten zetten?

Mijn punt is: het is niet rationeel om een goede oplossing met nauwelijks kosten af te wijzen ten faveure van een oplossing waar je later problemen mee verwacht. Onafhankelijk van andere risico's.

[Q]

dcm360 schreef op maandag 18 juli 2016 @ 14:15:
De server staat nog steeds in de kelder, en nu kost het meer moeite of misschien wel geld om de server naar de eerste verdieping te verplaatsen omdat in de tussentijd het netwerk veranderd is (een wellicht niet heel erg sterke vergelijking met: er staat data op de schijven, je kan er nu niet zomaar ZFS op zetten). Had je niet beter om mee te beginnen de server op de eerste verdieping moeten zetten?

De keuze om de kabels te upgraden staat los van de keuze om de server in de kelder te zetten.
De keuze om alsnog ECC toe te passen later staat helemaal los van de keuze om ZFS toe te passen.

De server staat nog steeds in de kelder en dat is een *separaat* risico. In je analogie is een overstroming een veel kleiner risico 1 op 10.000 dus is het volkomen rationeel om dat risico wel te accepteren maar niet langer die brakke kabels.

Je kunt er dus prima voor kiezen om een server met ECC neer te zetten en NTFS/XFS te blijven draaien.

Wil je dat risico OOK wegnemen, dat is een separate los staande, ongerelateerde en onafhankelijke beslissing.

Er moet iets significants veranderd zijn in je risico assessment dat de keuze kan verantwoorden om je server naar boven te migreren. Of je hebt een ernstige inschattingsfout begaan maar dat is een heel ander issue.

Mijn punt is: het is niet rationeel om een goede oplossing met nauwelijks kosten af te wijzen ten faveure van een oplossing waar je later problemen mee verwacht. Onafhankelijk van andere risico's.

Het grote probleem met je analogie is overigens dat de server boven plaatsen (ZFS kiezen) niet de 'goede' oplossing met nauwelijks nadelen is en dat had ik eerder moeten aanwijzen. Kennis, 'hidden cost' etc.

Zie ook in hoe onzinnig het zou zijn om de server met brakke kabels toch naar boven te verhuizen?
Je wel druk maken of de achterdeur op slot zit maar de voordeur open laten? Niet zo handig he?

Maar laten we de analogie eens verder verkennen.

Je plaatst de server boven ook al is het risico van 1 op 10.000 op een overstroming heel klein.
Door de server ruimte boven te plaatsen blijkt het bedrijf later tekort aan kantoor ruimte te hebben terwijl ze dat niet had gehad als de server in de kelder was geplaatst.

Achteraf had ze liever niet aan 'premature' optimalisatie gedaan voor een risico wat ze toch wel had durven nemen of had willen oplossen middels een BCP omdat die kosten lager waren geweest dan elders extra kantoor ruimte moeten huren in een 2e pand.

Achteraf blijkt die goede oplossing met nauwelijks kosten toch niet zo rooskleurig als gedacht. Had je je maar niet laten leiden door risico's die er niet toe doen of op een andere manier gemitigeerd konden worden (best of both worlds).

Moet ik nog uitschrijven hoe dit mapt op ZFS of je je dat zelf ook wel

Het is niet rationeel om je te laten leiden in je gedrag door risico's die je toch accepteert hoe gratis ze ook (lijken te) zijn.

[ Voor 8% gewijzigd door Q op 19-07-2016 00:41 ]

[dcm360]

Q schreef op dinsdag 19 juli 2016 @ 00:29:
[...]


De keuze om de kabels te upgraden staat los van de keuze om de server in de kelder te zetten.
De keuze om alsnog ECC toe te passen later staat helemaal los van de keuze om ZFS toe te passen.

Waarom geef je dan het advies om ZFS niet te gaan gebruiken als er initieel geen ECC geheugen aangeschaft wordt? (hier begon de hele discussie mee)

[...]
Verder verhaal weggehaald voor leesbaarheid

Naast dat ik geen idee heb waar BCP voor staat () ben ik het hier wel redelijk mee eens, op één punt na: je moet in de originele afweging uiteraard ook nadelen van ZFS meewegen, en dat die groter kunnen zijn dan de voordelen (in jouw geval: je zet de server neer in kantoorruimte waarvan je denkt dat de kans groter is dat je het nodig gaat hebben dan dat de kelder overstroomt).

Eigenlijk kan ik wel concluderen dat de keuze voor wel/geen ZFS (of ander FS*) belangrijker is dan de keuze voor ECC. De keuze voor ECC is makkelijker te corrigeren dan de keuze voor ZFS.

* Zo had ik zelf eigenlijk liever BTRFS gehad dan ZFS. Op dit moment zou ik ook zeker voor BTRFS gaan, maar die keuze was er enkele jaren geleden nog niet. Nu wisselen kost me echter aardig wat moeite en ook geld (want ik moet schijven kopen om data te kunnen migreren).

[player-x]

dcm360 schreef op dinsdag 19 juli 2016 @ 01:21:
Waarom geef je dan het advies om ZFS niet te gaan gebruiken als er initieel geen ECC geheugen aangeschaft wordt? (hier begon de hele discussie mee)

Ik moet eigenlijk niet meer met Q discussiëren, daar hij alles veel meer zwart en wit ziet, ik zelf zie gewoon veel meer grijswaardes, die hij niet wil of kan zien.

Hier twee quotes van hier boven, over hoe Q over wel of geen ZFS denkt, deze stellingen maken nagenoeg elke discussie onmogelijk...

Q schreef op maandag 14 december 2015 @ 12:40:
Het feit dat ZFS veiliger is voor je data dan NTFS is in de genoemde context niet relevant.

Want persoonlijk denk ik dat het voor de eindgebruikers juist wel super relevant is, dat ZFS zelfs zonder ECC veiliger is dan NTFS!

Q schreef op maandag 14 december 2015 @ 20:40:
ZFS is wel veiliger voor je data dan NTFS, maar in de context is dat niet relevant. Er zijn belangrijkere zaken.

Tja dat vind hij, dat er belangrijkere zaken zijn, dat is imho heel wat anders wat ik denk dat de meeste mensen willen met hun NAS.

[Q]

player-x schreef op dinsdag 19 juli 2016 @ 17:44:
Want persoonlijk denk ik dat het voor de eindgebruikers juist wel super relevant is, dat ZFS zelfs zonder ECC veiliger is dan NTFS!

Ik schreef het wat vijandiger op maar dat haal ik nu weg.

Ik vind zelf juist dat er een beeld wordt geschetst als:

ZFS = veiliger dan NTFS qua bitrot bescherming DUS beter.

Het is altijd 'beter' om ZFS te draaien dan NTFS/XFS/EXT4.

Dat vind ik dus zelf juist inflexibel en star.

Want het is echt niet zo dat je zonder ZFS enorme risico's loopt, in tegendeel. ZFS neemt een zeer klein risico weg. En van zeer kleine risico's is het zeer redelijk om te kiezen om deze te accepteren. En dat geldt ook voor ECC geheugen en mensen komen er mee weg. En soms niet.

Het gaat ook om de context van iemands skill set, kennis tijd/moeite en geld + wensen.

[ Voor 52% gewijzigd door Q op 19-07-2016 18:17 ]

[Q]

dcm360 schreef op dinsdag 19 juli 2016 @ 01:21:
[...]

Waarom geef je dan het advies om ZFS niet te gaan gebruiken als er initieel geen ECC geheugen aangeschaft wordt? (hier begon de hele discussie mee)

Daar heb ik het over het scenario dat je gaat upgraden. Dat je ECC gaat upgraden wil niet zeggen dat je het ZFS risico opeens anders gaat afwegen.

Maar pas als je ECC afdekt (groter risico), is het zinvol om ook naar ZFS te kijken.

Naast dat ik geen idee heb waar BCP voor staat ()

Sorry, Business Continuity Planning (momenteel een hot topic bij ons op het werk )

Ben ik het hier wel redelijk mee eens, op één punt na: je moet in de originele afweging uiteraard ook nadelen van ZFS meewegen, en dat die groter kunnen zijn dan de voordelen (in jouw geval: je zet de server neer in kantoorruimte waarvan je denkt dat de kans groter is dat je het nodig gaat hebben dan dat de kelder overstroomt).

Ja precies.

Eigenlijk kan ik wel concluderen dat de keuze voor wel/geen ZFS (of ander FS*) belangrijker is dan de keuze voor ECC. De keuze voor ECC is makkelijker te corrigeren dan de keuze voor ZFS.

Sorry, maar kiezen voor non-ecc is meestal moederbord + proc vervangen als je ECC wilt
Dus beide keuzes moeten afgewogen genomen worden. Je bedenken is kostbaar.

* Zo had ik zelf eigenlijk liever BTRFS gehad dan ZFS. Op dit moment zou ik ook zeker voor BTRFS gaan, maar die keuze was er enkele jaren geleden nog niet. Nu wisselen kost me echter aardig wat moeite en ook geld (want ik moet schijven kopen om data te kunnen migreren).

Ik zou ook liever BTRFS draaien om deze reden.

[vanaalten]

dcm360 schreef op dinsdag 19 juli 2016 @ 01:21:
* Zo had ik zelf eigenlijk liever BTRFS gehad dan ZFS. Op dit moment zou ik ook zeker voor BTRFS gaan, maar die keuze was er enkele jaren geleden nog niet. Nu wisselen kost me echter aardig wat moeite en ook geld (want ik moet schijven kopen om data te kunnen migreren).

Ik ben een jaartje terug of zo ook overgestapt van ZFS-on-Linux naar BTRFS (motivatie: ik wilde op m'n NAS bij voorkeur alleen distributie-repositories gebruiken) en dat ging zonder dat ik extra schijven nodig had:
ZFS mirror van twee schijven --> 1 ZFS disk, 1 disk 'ongebruikt'; daarna ongebruikte disk als BTRFS formatteren en data kopieeren; daarna de ZFS disk als BTRFS formatteren en toevoegen als mirror aan BTRFS pool.

Ik zou gokken dat dat bij de meeste ZFS-opstellingen zo kan, je hoeft maar voldoende capaciteit los te halen van je pool om zo te kunnen migreren. Ja, je hebt wel een korte periode dat je data op slechts 1 disk (of set) beschikbaar is, dus als dan een disk kapot gaat baal je wel...

[dcm360]

vanaalten schreef op dinsdag 19 juli 2016 @ 21:04:
[...]
Ik zou gokken dat dat bij de meeste ZFS-opstellingen zo kan, je hoeft maar voldoende capaciteit los te halen van je pool om zo te kunnen migreren. Ja, je hebt wel een korte periode dat je data op slechts 1 disk (of set) beschikbaar is, dus als dan een disk kapot gaat baal je wel...

Het maakt het niet heel veel handiger als je echter RAID-Z sets hebt die meer dan voor de helft gevuld zitten. Met de 2 sets van 3 schijven die ik heb, zou ik dus van beiden de redundantie moeten weghalen, met de weggehaalde schijven een degraded set aanmaken waar de kleinste set heen kan, en vervolgens de wat grotere set met wat jongleren op dezelfde manier ook omzetten. Het kan wel, daar niet van, maar het zou er op neer komen dat ik gedurende het hele proces zware I/O ga loslaten op 3 striped sets met data die ik met reden normaalgesproken in RAID-Z heb.

[albatross]

Verwijderd schreef op zondag 21 juni 2015 @ 14:16:
[...]

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.

Die nuchterheid van je, dat mag ik wel!

Ik wil inderdaad dat mijn film collectie het overleeft. Dat kan met ZFS, zoals je beargumenteert, sowieso een stuk beter, met of zonder ECC.

En budget mag dan voor Q niet uitmaken (en dat doet het ook niet, voor de academische discussie), maar voor een thuisbegruiker als ik, die gewoon nog een prima i7 machine heeft staan, is die extra duizend euro voor een volledig nieuwe ECC machine het gewoon niet waard. Kosten/baten en zo.

Bovendien, zo redeneer ik altijd, als je geheugen het begeeft, ben je toch al f*cked, want dat raakt ook het geheugen van je OS (blue/pink screens of death). Dus dat merk je waarschijnlijk snel genoeg.

[Q]

albatross schreef op donderdag 11 augustus 2016 @ 18:17:
[...]

Ik wil inderdaad dat mijn film collectie het overleeft. Dat kan met ZFS, zoals je beargumenteert, sowieso een stuk beter, met of zonder ECC.

En budget mag dan voor Q niet uitmaken (en dat doet het ook niet, voor de academische discussie), maar voor een thuisbegruiker als ik, die gewoon nog een prima i7 machine heeft staan, is die extra duizend euro voor een volledig nieuwe ECC machine het gewoon niet waard. Kosten/baten en zo.

Bovendien, zo redeneer ik altijd, als je geheugen het begeeft, ben je toch al f*cked, want dat raakt ook het geheugen van je OS (blue/pink screens of death). Dus dat merk je waarschijnlijk snel genoeg.

Ik vind de manier hoe jij mijn positie portretteert onjuist. Ik hou rekening met budget.

Verder is je redenatie over geheugen onjuist, het OS zit maar in een klein stukje van het geheugen dus afhankelijk van de getroffen regio kan er een hoop data silent gecorrupt worden door rot werkgeheugen eer jij iets door krijgt.

Ik begrijp dat je film collectie gewoon zo belangrijk is dat je geen cent extra wilt besteden om deze beter te beschermen tegen een bekend risico en dat is prima verder. Mensen met QNAPs en Synologies doen het ook zo.

Maar die draaien ook geen ZFS.

[albatross]

Q schreef op donderdag 11 augustus 2016 @ 19:29:
[...]


Ik vind de manier hoe jij mijn positie portretteert onjuist. Ik hou rekening met budget.

"(groot verschil is dat ZFS gratis is en ECC geld kost, maar dat is niet de discussie)."

Maar dat is uiteraard wel (mede) de discusie, want het antwoord op de academische vraag of je ECC zou moeten gebruiken is natuurlijk immer: Ja. Terwijl, in de echte wereld, een nieuwe ECC machine, met flink wat geheugen, een behoorlijke smak extra geld is.

Ik begrijp dat je film collectie gewoon zo belangrijk is dat je geen cent extra wilt besteden om deze beter te beschermen tegen een bekend risico en dat is prima verder.

Ouch, wat een verbeten reactie! En over verkeerd portretteren van iemands positie gesproken, LOL. Persoonlijk prefereer ik de nuance van CIPHER. Het gaat niet om 'alles of niets.' Mensen willen uiteraard hun data behouden, maar zijn niet direkt bereid een slordige extra duizend euro uit te geven voor 'enterprise-grade' data-integriteit. Zeker terwijl een hoop van die fouten, zoals CIPHER aangaf, gewoon transient van aard zijn, en je ze waarschijnlijk nooit echt tegen zult komen.

[Kortfragje]

Ik wil graag mijn € 0.02 toevoegen.

Ik ben het met Cipher in zoverre eens dat er een nuance is, het is niet zwart wit. ZFS is voor zover ik kan beoordelen, gebaseerd op de beperkte literatuur, niet nutteloos zonder ECC. Het verhaal over pool verlies door slecht geheugen, ik vind dat moeilijk te geloven.

Aan de andere kant ben ik het deels met Q eens. Ik draai wel ECC thuis (op mijn hoofdserver die altijd aan staat), mijn backup zfs server heeft geen ECC. De reden daarvoor is dat ik redeneerde als volgt: als ik veel geld ga steken in disks (in mijn geval de bulk van de kosten) waarom dan niet die € 150 extra voor de extra piece of mind (totaal verschil tussen een ECC enabled oplossing en ECC disabled). Ik gebruik zelf AMD + een ASUS mobo (ondersteund ECC voor een fractie van de intel based price).

Dat betekent inderdaad dat het niet eenvoudig is hardware te hergebruiken...

Maar tot iemand mij de echte kansen kan schetsen is dit allemaal een discussie van welles / nietes.

Bijvoorbeeld:

• wat is de kans op een memory bitflip? we hebben alleen de aangehaalde google studie
• wat is de kans op een URE? volgens mij gebruiken individuele disks error correcting code (ecc...)

wat ik wel weet is dat zfs nu al een aantal keer fouten van een paar blocks gecorrigeerd heeft bij mij (zie zfs topic), bij gebruik van 5TB disks.

Voor mij werkt dit, ik vond het de kosten waard. m.i. kan je niemand overtuigen van je gelijk zonder ECHT onderbouwing van je punt...

ps. mijn server staat in de trapkast en de backup op de 1e verdieping

[Q]

albatross schreef op donderdag 11 augustus 2016 @ 19:46:
[...]


"(groot verschil is dat ZFS gratis is en ECC geld kost, maar dat is niet de discussie)."

Maar dat is uiteraard wel (mede) de discusie, want het antwoord op de academische vraag of je ECC zou moeten gebruiken is natuurlijk immer: Ja. Terwijl, in de echte wereld, een nieuwe ECC machine, met flink wat geheugen, een behoorlijke smak extra geld is.

Het feit is dat iedere server van HP of dell, vanaf 200 euro met ECC geheugen wordt verkocht en dat is met een reden.

Als jij een meerprijs van 150-200 euro een behoorlijke smak geld vind, prima dat mag je vinden. Een ander vind zijn/haar data dat prima waard.

Maar overdrijven en bagatelliseren is fout. Je kiest om budgettaire redenen een bepaald risico te accepteren.

Het grappige is juist dat je een veel groter risico accepteert wat je met relatief lage kosten kunt voorkomen en je dan wel druk gaat lopen maken over ZFS alleen maar om dat het gratis is.

ouch, wat een verbeten reactie! En over verkeerd portretteren van iemands positie gesproken, LOL.

Je zegt at je data belangrijk is, maar het mag vooral niets kosten en je probeert nu excuses te verzinnen om je standpunt goed te praten. Je bent niet de eerste hoor.

Maar wat je doet is simpel: je neemt gewoon een bewust risico met je data. Dat druist in tegen je statement dat je je data zo belangrijk vind.

Persoonlijk prefereer ik de nuance van CIPHER. Het gaat niet om 'alles of niets.' Mensen willen uiteraard hun data behouden, maar zijn niet direkt bereid een slordige extra duizend euro uit te geven voor 'enterprise-grade' data-integriteit. Zeker terwijl een hoop van die fouten, zoals CIPHER aangaf, gewoon transient van aard zijn, en je ze waarschijnlijk nooit echt tegen zult komen.

Wat je schrijft is geen goede voorstelling van zaken.CiPHER kan helemooie woorden als 'transient' gebruiken maar het feit is dat rot geheugen gewoon silent data corruptie en/of verlies van je pool kan betekenen. Dat risico is niet groot, maar zeker niet nul. Dat is waarom er ECC geheugen zit in ieder server component wat je koopt.

De realiteit is dat als je echt om je data geeft dat je dan ook woord bij daad voegt en betaalt om het reële risico weg te nemen. En anders neem je bewust een risico.

Het is niet waar dat het duizend euro meer kost om ECC toe te passen, over nuance gesproken.

Je noemt het 'enterprise-grade' 'data-integriteit' als je naar ECC verwijst. Dat noem je zo om er de spot mee te drijven en het af te serveren als onnodig voor thuis. Maar je vergeet dat deze sticker ook op ZFS kan worden geplakt. Dus als je consistent wilt zijn is er ook geen noodzaak voor ZFS in jouw situatie.

Als je ECC geheugen niet nodig vind, dan is ZFS ook niet nodig. Nog steeds prima om ZFS toe te passen, ZFS heeft ook andere leuke features. Maar dan vervolgens doen alsof je 'veilig' bezig bent voor je data, dat is flauwekul.

Kortfragje schreef op donderdag 11 augustus 2016 @ 23:13:
Het verhaal over pool verlies door slecht geheugen, ik vind dat moeilijk te geloven.

Iedere write naar disk met rot geheugen heeft de potentie om je pool te verkloten. Met name als rot geheugen ZFS metadata treft en dus silent corrumpeert. En iedere ZFS write is een uberblock update....

Dit is natuurlijk een probleem wat niet ZFS-specifiek is. Het enige 'positieve' van legacy file systems is dat de FSCK/chkdisk tools de boel nog wel eens voor je kunnen herstellen. Met ZFS is of alles nog OK, of je bent alles kwijt. Maar je wilt nooit in deze positie komen. Althans, ik zou het zelf niet willen.

[ Voor 11% gewijzigd door Q op 11-08-2016 23:38 ]

[Kortfragje]

Q schreef op donderdag 11 augustus 2016 @ 23:22:
[...]


Iedere write naar disk met rot geheugen heeft de potentie om je pool te verkloten. Met name als rot geheugen ZFS metadata treft en dus silent corrumpeert. En iedere ZFS write is een uberblock update....

Dit is natuurlijk een probleem wat niet ZFS-specifiek is. Het enige 'positieve' van legacy file systems is dat de FSCK/chkdisk tools de boel nog wel eens voor je kunnen herstellen. Met ZFS is of alles nog OK, of je bent alles kwijt. Maar je wilt nooit in deze positie komen. Althans, ik zou het zelf niet willen.

Mee eens, vandaar mijn keuze voor ECC. Maar zouden we niet meer 'pool losses' moeten zien ? Wat zijn de echte kansen?

gegeven een server van 10-20 TB, thuisgebruik, draait 4 jaar voor vervanging. Hoeveel disk based errors, memory based errors, etc, zien je gedurende die periode? En wat is het destructieve potentieel? Dat zijn de feiten die je nodig hebt om een echte evidence based beslissing te maken.

In afwezigheid daarvan, kies ik voor de extra zekerheid van ECC (zeker voor de filmpjes en foto's van mn kinderen....). Dat is mijn keuze, ik vindt het dat waard.

[albatross]

Q schreef op donderdag 11 augustus 2016 @ 23:22:
[...]

Het feit is dat iedere server van HP of dell, vanaf 200 euro met ECC geheugen wordt verkocht en dat is met een reden.

Als jij een meerprijs van 150-200 euro een behoorlijke smak geld vind, prima dat mag je vinden. Een ander vind zijn/haar data dat prima waard.

Wie heeft het over meerprijs?! Dat gaat alleen op voor wie nog geen server heeft. Veel thuisgebruikers kopen ooit een nieuwe desktop, en hebben dan dus nog een leuke i7 bak staan, of iets dergelijks, en besluiten vervolgens om er nog iets leuks mee te doen, zoals het bouwen van een NAS (en blijven die cycles herhalen bij iedere verdere aanschaf van een nieuwe computer). Dan betekent ECC, zeker als je ook nog iets anders met die machine wil gaan doen dan alleen maar ZFS, dat je toch een redelijk prijzige machine aan moet schaffen (met zo'n 16G ECC geheugen). En dan is een extra duizend euro een heel redelijke schatting.

Je kiest om budgettaire redenen een bepaald risico te accepteren.

We noemen dat in de gewone wereld een kosten-batenanalyse. Zo heb ik in al mijn 25+ jaar computer ervaring nog nooit te kampen gehad met stuk geheugen. Wil dat zeggen dat ECC geheugen dus niet nodig is? Nee; maar wel dat je dingen best een beetje mag relativeren.

Je zegt at je data belangrijk is, maar het mag vooral niets kosten en je probeert nu excuses te verzinnen om je standpunt goed te praten.

Je schiet weer in de hyperbole.

Maar wat je doet is simpel: je neemt gewoon een bewust risico met je data. Dat druist in tegen je statement dat je je data zo belangrijk vind.

En nu weer. Probeer de wereld nou toch eens niet zo zwart-wit te zien. Het gaat niet tussen 'het mag vooral niets kosten' en 'totaal wel- of totaal niet je data belangrijk vinden.' Het gaat mensen om de vraag wat een bepaald risico hen waard is. Het leven zit vol van dat soort beslissingen. Neem ik een 'all risk' verzekering, met hoge kosten, of vind ik de gewone rechterlijke aansprakelijkheid wel voldoende? Neem ik nog een extra glasverzekering voor mijn iPhone, of denk ik dat ik het wel uitzing zonder? Dat is niet 'excuses verzinnen om je standpunt goed te praten', maar gewoon een verstandige kosten-batenanalyse.

CiPHER kan helemooie woorden als 'transient' gebruiken maar het feit is dat rot geheugen gewoon silent data corruptie en/of verlies van je pool kan betekenen. Dat risico is niet groot, maar zeker niet nul.

En dat is nou precies waar het om gaat. Over de vraag dus wat dat 'niet groot, maar zeker niet 0' risico iemand waard is.

Je noemt het 'enterprise-grade' 'data-integriteit' als je naar ECC verwijst. Dat noem je zo om er de spot mee te drijven en het af te serveren als onnodig voor thuis.

Zoals CIPHER heel goed uitgelegd heeft, zijn er idd risico's die voor een thuis-situatie wel toelaatbaar zijn, en in een enterprise situatie beslist niet. Zo mag er bij een bank inderdaad nooit een bitje omvallen, om dan te zien dat er 10 Miljard overgemaakt was, ipv 10 Miljoen. Maar op je home NAS, gaat daar de wereld verloren als er ooit een kleine transient error plaatsvindt in een film van mij? Niet bepaald; want de kans dat ik net toevallig op dat moment *die* film aan het kijken ben, is totaal verwaarloosbaar. Waar daarentegen de kans dat de fout zichzelf weer heeft hersteld, voordat ik er ooit achter kom, veel groter is.

Maar dan nog, je weet dat een RAID/ZFS geen backup is, right?! We hebben het dus over een minieme kans dat je ooit een file echt corrupt zult zien. In welk geval je terugvalt op je backup voor dat ene bestand. Voor veel mensen is dat een hele redelijke dekking van het reele risico.

[player-x]

Kortfragje schreef op donderdag 11 augustus 2016 @ 23:13:

• wat is de kans op een memory bitflip? we hebben alleen de aangehaalde google studie

Dat is ook mijn punt, elke keer wordt die studie aangehaald door Q, en ja de studie is interessant, maar hoe relevant is het voor een thuis gebruiker?

Google's servers hebben vast een gemiddelde geheugen I/O load van rond de 50~80%, mijn server 1~2%, daarnaast zijn het overgrote deel van de HDD I/O's lees acties, en dan is de impact van een bitflip verwaarloosbaar.

Daarnaast hebben we ook hele andere data, bij video data zijn de gevolgen van een bitflip meestal niet eens of nauwelijks merkbaar.

Q heeft een sterke mening, dat is prima, maar imho brengt hij veel onnodige (onopzettelijke) FUD in de discussie.

Ik ga niet verklaren dat ECC, niet nodig is, want in een bedrijfsomgeving is het gewoon een must, en ik gebruik zelf tegenwoordig (jaren zonder gedraaid) ook ECC in al mijn servers, maar ik heb dan ook een 80TB main (10x 8TB), 70TB mirror (24x 3TB) en een 11TB offline (16x 750GB) backup server draaien in die laatste had ik een mobo met een PCI-X controller nodig, en ECC kwam daar gratis bij.

Het probleem van Q zijn stellingname is, is imho, dat hij er van overtuigt is dat zijn gebruikersmodel een blauwdruk is voor iedere ZFS/BtrFS gebruiker.

Ik zou best wel eens een studie willen zien, waar de Google data wordt gebruikt, om te zien wat de gevolgen zijn voor een thuisgebruiker zijn gebruikspatronen, want als ik daar gezonde boerenverstand op los laat, zijn die risico's maar nihil toen ik er een grove servetje berekening op los liet, met flink wat aannames van mijn kant.

Ik zeg niet dat Q geen ongelijk kan hebben, maar ik zie of hoor nergens dat ZFS thuis servers zonder ECC significant onveiliger zijn dan met ECC, het grootste probleem is, er is gewoon geen data om de een of andere stelling te ondersteunen.

Tot dan, blijft mijn advies, gebruik gewoon ZFS als je de tijd er wil in stekken, het is veiliger dan ext4 of NTFS, zelfs zonder ECC, maar gebruik ECC als het in je budget zet zit, want nieuw is het tegenwoordig maar een paar tientjes meer, want het kan nooit kwaad, en kijk altijd naar die HP Microservers met ECC, als 4+2 disks voldoende is, kan je niets vergelijkbaars zelf bouwen wat goedkoper is, en je krijgt er ook nog een ECC bij.

[Q]

albatross schreef op vrijdag 12 augustus 2016 @ 00:29:
[...]


Wie heeft het over meerprijs?! Dat gaat alleen op voor wie nog geen server heeft. Veel thuisgebruikers kopen ooit een nieuwe desktop, en hebben dan dus nog een leuke i7 bak staan, of iets dergelijks, en besluiten vervolgens om er nog iets leuks mee te doen, zoals het bouwen van een NAS (en blijven die cycles herhalen bij iedere verdere aanschaf van een nieuwe computer). Dan betekent ECC, zeker als je ook nog iets anders met die machine wil gaan doen dan alleen maar ZFS, dat je toch een redelijk prijzige machine aan moet schaffen (met zo'n 16G ECC geheugen). En dan is een extra duizend euro een heel redelijke schatting.

Je hoeft alleen moederbord, geheugen en cpu te vervangen, dus dat hoeft niet meer dan ~300 euro te kosten. Geen duizend.

Je overdrijft.

We noemen dat in de gewone wereld een kosten-batenanalyse. Zo heb ik in al mijn 25+ jaar computer ervaring nog nooit te kampen gehad met stuk geheugen. Wil dat zeggen dat ECC geheugen dus niet nodig is? Nee; maar wel dat je dingen best een beetje mag relativeren.

Tja, argumenten op basis van anekdotes, nutteloos. Ik heb het wel een paar keer mee gemaakt.

En nu weer. Probeer de wereld nou toch eens niet zo zwart-wit te zien.

Roepen dat iemand zwart/wit denkt maakt het nog niet waar.

Het gaat niet tussen 'het mag vooral niets kosten' en 'totaal wel- of totaal niet je data belangrijk vinden.' Het gaat mensen om de vraag wat een bepaald risico hen waard is.

Het leven zit vol van dat soort beslissingen. Neem ik een 'all risk' verzekering, met hoge kosten, of vind ik de gewone rechterlijke aansprakelijkheid wel voldoende? Neem ik nog een extra glasverzekering voor mijn iPhone, of denk ik dat ik het wel uitzing zonder? Dat is niet 'excuses verzinnen om je standpunt goed te praten', maar gewoon een verstandige kosten-batenanalyse.

Maar dat is de discussie niet en dat mis je dus helemaal.

Wat jij doet en velen proberen te doen is de keuze voor ZFS zonder ECC geheugen goed te praten als in: dat is veiliger voor mijn data. En dat is onzin.

Van de twee risico's accepteer je een veel groter risico wel omdat het geld kost, maar omdat het afdekken van een kleiner risico gratis is doe je alsof je verstandig bezig bent en noem je dat 'genuanceerd'.

Dat is onzin, als je de grote risico's niet afdekt maakt het verder niet meer uit wat je doet.

Zoals CIPHER heel goed uitgelegd heeft, zijn er idd risico's die voor een thuis-situatie wel toelaatbaar zijn, en in een enterprise situatie beslist niet. Zo mag er bij een bank inderdaad nooit een bitje omvallen, om dan te zien dat er 10 Miljard overgemaakt was, ipv 10 Miljoen. Maar op je home NAS, gaat daar de wereld verloren als er ooit een kleine transient error plaatsvindt in een film van mij? Niet bepaald; want de kans dat ik net toevallig op dat moment *die* film aan het kijken ben, is totaal verwaarloosbaar.

Dus waarom ZFS dan met deze redenatie? Je zit toch niet in een enterprise situatie?

Waar daarentegen de kans dat de fout zichzelf weer heeft hersteld, voordat ik er ooit achter kom, veel groter is.

Weer onjuist, rot geheugen kan tot silent data corruptie en pool verlies leiden bij een write. Een tijdelijke bitflip die zichzelf hersteld bij het afspelen van een film is een best-case scenario.

Maar dan nog, je weet dat een RAID/ZFS geen backup is, right?! We hebben het dus over een minieme kans dat je ooit een file echt corrupt zult zien. In welk geval je terugvalt op je backup voor dat ene bestand. Voor veel mensen is dat een hele redelijke dekking van het reele risico.

Oh werkelijk? Dat wist ik niet, goed dat je dit uitlegt. Nooit bij stil gestaan. Maak jij dan een 1-op-1 kopie van je film collectie? Ga je twee servers neerzetten dan, een met een backup historie? Is wel duur hoor, vast wel meer dan duizend euro.

De grap is dat je zonder ECC geheugen ook nooit zult weten of je bestanden corrupt zijn of niet want ZFS helpt je op dat vlak niet.

[Q]

player-x schreef op vrijdag 12 augustus 2016 @ 07:01:
Tot dan, blijft mijn advies, gebruik gewoon ZFS als je de tijd er wil in stekken, het is veiliger dan ext4 of NTFS, zelfs zonder ECC

@Player-X ik reageer op dit stukje, maar het is niet persé gericht op jou specifiek

Als je geen ECC geheugen gebruikt dan is het in mijn beleving totale onzin om je druk te maken over het aantoonbaar veel kleinere risico waar ZFS tegen beschermt.

Prima als je ZFS toepast, maar met als argument - het is veiliger - dat argument klopt gewoon niet. Die vermeende extra veiligheid valt in het niet bij het risico wat je er naast neemt.

Letop, ik ontken niet dat ZFS tegen een risico beschermt wat de andere filesystems met uitzondering van BTRFS niet kunnen. ZFS neemt een bepaald risico weg. Maar op basis daarvan roepen: ZFS is dus veiliger = geen rekening houden met de context.

Dat is nu de nuance die ik zelf dus mis. Het is niet logisch om je druk te maken over hele kleine risico's als je veel grotere risico's negeert.

Ergens is dat bevrijdend, want dat maakt het redelijk om gewoon voor een legacy file system / RAID oplossing te kiezen, iets wat beter bij iemands situatie kan passen. Je draait dan op het veiligheidsniveau van een Synology of Qnap. Voor thuis lijkt me daar niets mis mee.

Ik vind het ook redelijk om die reden als je er voor kiest om thuis geen ECC te draaien. Als Synology of Qnap het niet doet, waarom ik dan wel? (same for ZFS). Ik ben geen ECC fascist, alhoewel dat zo soms mag lijken. Het gaat mijn om de context en de redenatie.

Als je toch voor ZFS gaat, prima, ik zeg niet dat je het niet moet doen. Ik zeg alleen dat je zonder ECC en ZFS een vals gevoel van veiligheid creëert die je mogelijk wel afhoudt van een oplossing die beter bij je past en waarvan het 'extra' risico relatief verwaarloosbaar is.

Toegegeven, als je bijvoorbeeld goed bent met BSD/Linux dan is dat misschien geen relevant argument en maakt die optie niet zoveel uit. Veel mensen zouden liever voor Windows of Linux met een andere oplossing kiezen omdat dit bij hun kennis, kunde en vaardigheid past, maar worden soms een beetje door FUD vanuit het ZFS kamp richting ZFS gepusht, koste-wat-het-kost-want-het-is-veiliger. En dat vind ik jammer.

[GeeMoney]

Even een totaal andere insteek in deze discussie:

Als je data zo belangrijk is, maak je dan niet hoofdzakelijk druk om het FS en/of ECC verhaal maar maak je minstens zo druk om je back-up/recovery.
Ik heb geen ZFS toegepast omdat ik mijn back-up en recovery zaken goed voor elkaar heb. Als ik mijn huidige pool/RAID opstelling al zou verliezen is dat geen ramp, hooguit vervelend.

De rust die een Synology mij dan ook geeft (rust als in, geen tijd aan beheer nodig)in combinatie met mijn back-up/recovery zijn mij meer waard dan ZFS met of zonder ECC en vervolgens geen back-up/recovery.

Ik ben met de meeste eens volgens mij dat ALS je het 1 kiest, je eigenlijk ook het ander moet kieen. (ZFS + ECC dus).

Je koopt een auto met 4 wielen maar eigenlijk zet je er altijd 3 op spanning en 1 controleer je nooit. (want die andere 3 zijn eigenlijk altijd goed)

[Q]

Conceptueel beschermt een backup niet echt tegen silent data corruptie. Hooguit kan het de impact mitigeren als je een goede backup historie hebt en desnoods ver terug in de tijd kunt gaan. Maar zoiets kost vaak weer extra storage.

Veel mensen die hun media op hun (zelfbouw) NAS opslaan, maken daar geen backups van. Dat wordt te duur, zelfs voor mij

Toch wil ik ook mijn media niet verliezen, het is inmiddels een aardige collectie waar wat tijd in heeft gezeten. Alhoewel een backup oplossing mij te duur wordt, heb ik er voor gekozen om dan de machine waar de media op staat zo robuust mogelijk te maken, met ECC geheugen en ZFS.

Dit is geen echte substituut voor een backup natuurlijk, maar binnen wat mogelijk is, is de combo ECC + ZFS een goede optie. Alhoewel ik vaak over ZFS zeik is het geen verkeerde opties, zolang je maar een gewogen keuze maakt.

Kritische data gaat bij mij gewoon (ook) naar Backblaze. Daarvan maak ik wel backups. (en ook nog lokaal via timemachine).

[ Voor 18% gewijzigd door Q op 12-08-2016 11:44 ]

[GeeMoney]

Q schreef op vrijdag 12 augustus 2016 @ 11:43:
Conceptueel beschermt een backup niet echt tegen silent data corruptie. Hooguit kan het de impact mitigeren als je een goede backup historie hebt en desnoods ver terug in de tijd kunt gaan. Maar zoiets kost vaak weer extra storage.

Veel mensen die hun media op hun (zelfbouw) NAS opslaan, maken daar geen backups van. Dat wordt te duur, zelfs voor mij

Toch wil ik ook mijn media niet verliezen, het is inmiddels een aardige collectie waar wat tijd in heeft gezeten. Alhoewel een backup oplossing mij te duur wordt, heb ik er voor gekozen om dan de machine waar de media op staat zo robuust mogelijk te maken, met ECC geheugen en ZFS.

Dit is geen echte substituut voor een backup natuurlijk, maar binnen wat mogelijk is, is de combo ECC + ZFS een goede optie. Alhoewel ik vaak over ZFS zeik is het geen verkeerde opties, zolang je maar een gewogen keuze maakt.

Kritische data gaat bij mij gewoon (ook) naar Backblaze. Daarvan maak ik wel backups. (en ook nog lokaal via timemachine).

Tsja, om nu niet weer een hele lange discussie te starten met afwijkend onderwerp aan de TS.

Feitelijk doe je hetzelfde als waar de discussie over gaat.
Je kiest wel voor ZFS+ECC maar vervolgens niet voor een back-up. Dit maakt je net zo kwetsbaar (procentueel) als wel ZFS zonder ECC maar wel met een goede back-up.

Silent data corruptie is een veel aangehaald argument om ZFS/BTRFS te kiezen maar feitelijke cijfers over hoe vaak dit voorkomt en ook nog eens destructief is, zijn er niet echt.
De keren dat mensen brand hebben, lekkage,een crash of diefstal waarbij de PC/NAS verloren gaat en dus ook de foto's/video's zijn wel inzichtelijk.

[albatross]

GeeMoney schreef op vrijdag 12 augustus 2016 @ 11:50:
[...]


Feitelijk doe je hetzelfde als waar de discussie over gaat.
Je kiest wel voor ZFS+ECC maar vervolgens niet voor een back-up. Dit maakt je net zo kwetsbaar (procentueel) als wel ZFS zonder ECC maar wel met een goede back-up.

En zelfs met een backup ben je er nog niet, want eigenlijk zou dan je hele 'track', backup incluis, ook ECC-beschermd moeten wezen (een keten is immers zo sterk als de zwakste schakel). En dat gaat voor een thuis-situatie toch wel erg ver, en toont goed aan dat het hele ECC verhaal erg veel fear-mongering bevat. Ik heb een (non-ECC) server ingericht als NAS, en een backup van mijn data op een stel goedkopere Seagate 5T schijven (die immers toch geen 24/7 aan hoeven te staan). Dan zou zowel mijn NAS data corrupt moeten wezen, als ook mijn backup data, voordat ik totally f*cked ben. Zelf vind ik dat me dat veilig genoeg maakt.

[Q]

ECC, ZFS het is allemaal fear-mongering.
De rest van de wereld koopt gewoon een Synology of Qnap.

Als jouw backup methode geen historie opbouwt dan is jouw backup strategie relatief gevaarlijk, ongeacht deze hele ECC/ZFS discussie. Want 1 (menselijke) fout op je brondata en als je niet oplet wordt die fout bij de volgende backup actie gerepliceerd en is je backup ook weg.

Bouw je een deftige historie op in de stijl van timemachine bijvoorbeeld dan is er denk ik niet zoveel te vrezen.

[begintmeta]

Q schreef op vrijdag 12 augustus 2016 @ 15:28:
ECC, ZFS het is allemaal fear-mongering.
De rest van de wereld koopt gewoon een Synology of Qnap.

Als jouw backup methode geen historie opbouwt dan is jouw backup strategie relatief gevaarlijk, ongeacht deze hele ECC/ZFS discussie. Want 1 (menselijke) fout op je brondata en als je niet oplet wordt die fout bij de volgende backup actie gerepliceerd en is je backup ook weg.

Bouw je een deftige historie op in de stijl van timemachine bijvoorbeeld dan is er denk ik niet zoveel te vrezen.

Maar je moet de fout in de data hoe dan ook wel tijdig herkennen natuurlijk, daarom blijf ik er ook bij dat integriteitscontrole in ieder geval op applicatieniveau zou moeten plaatsvinden, alleen in veel gevallen zijn de programma's daar niet op gebouwd.

[ Voor 10% gewijzigd door begintmeta op 12-08-2016 16:41 ]

[Kortfragje]

albatross schreef op vrijdag 12 augustus 2016 @ 13:38:
[...]


En zelfs met een backup ben je er nog niet, want eigenlijk zou dan je hele 'track', backup incluis, ook ECC-beschermd moeten wezen (een keten is immers zo sterk als de zwakste schakel). En dat gaat voor een thuis-situatie toch wel erg ver, en toont goed aan dat het hele ECC verhaal erg veel fear-mongering bevat. Ik heb een (non-ECC) server ingericht als NAS, en een backup van mijn data op een stel goedkopere Seagate 5T schijven (die immers toch geen 24/7 aan hoeven te staan). Dan zou zowel mijn NAS data corrupt moeten wezen, als ook mijn backup data, voordat ik totally f*cked ben. Zelf vind ik dat me dat veilig genoeg maakt.

Goed punt, daarom heb ik zfs +ecc op mn nas en zfs zonder ecc op backup. in principe komt de data dan goed aan via send / receive. en gezien de backup merendeel vd tijd uitstaat en de data statische is lijkt t me redelijk veilig...

maarja, statistieken om het te onderbouwen...


wel doe ik via zfs redelijke historie opbouwen (maandelijkse snap shots) en gaat de echt belangrijke data naar crashplan en een cold backup op ntfs....

[Q]

We hebben het nu wat meer over backup maar minstens zo belangrijk is weten of je backup in orde is. Klote om er achter te komen dat je backup al 2 maanden niet meer liep en nu je storage dood is.

Zoveel mensen hier die zelf een NAS bouwen omdat geen enkele monitoring en alerting in te regelen voor problemen in de storage of backup. Monitoring van de backup is echt out-of-scope voor dit topic.

Voor ZFS heb ik dit kleine artikeltje gemaakt voor monitoring.
http://louwrentius.com/the-zfs-event-daemon-on-linux.html

Wat je keuze ook is, als je ZFS draait, of MDADM of hardware RAID, configureer je monitoring en alerting.

[player-x]

Q schreef op vrijdag 12 augustus 2016 @ 07:57:
Als je geen ECC geheugen gebruikt dan is het in mijn beleving totale onzin om je druk te maken over het aantoonbaar veel kleinere risico waar ZFS tegen beschermt.

Prima als je ZFS toepast, maar met als argument - het is veiliger - dat argument klopt gewoon niet. Die vermeende extra veiligheid valt in het niet bij het risico wat je er naast neemt.

Dat is alleen waar als jouw aannames kloppen, wat betreft het risico van het gebruik van ECC, en daar geloof ik persoonlijk helemaal niks van!

Zoals ik al zij, ik zie problemen met jouw stellingname, wat betreft ECC, en dat je overtuigt bent dat jouw gebruikersmodel zoals jij dat ziet, een blauwdruk is voor iedere ZFS/BtrFS gebruiker, en daarnaast ga je imho ook nog eens uit van verkeerde aannames wat betreft het risico voor de thuisgebruiker.

quote: Mezelf net hier boven

Ik zou best wel eens een studie willen zien, waar de Google data wordt gebruikt, om te zien wat de gevolgen zijn voor een thuisgebruiker zijn gebruikspatronen, want als ik daar gezonde boerenverstand op los laat, zijn die risico's maar nihil toen ik er een grove servetje berekening op los liet, met flink wat aannames van mijn kant.

Google's servers hebben vast een gemiddelde geheugen I/O load van rond de 50~80%, mijn server 1 misschien 2%, daarnaast zijn het overgrote deel van de HDD I/O's lees acties, en dan is de impact van een bitflip verwaarloosbaar.

Elke keer als ik jouw argumenten lees, denk ik dat je appels met peren loopt te vergelijken, en dat je tunnel visie hebt, als bitflips echt zo een groot risico was, dan hadden ook alle bedrijfsmatige machines ECC geheugen gehad, maar ik zie nergens op mijn werk algemeen gebruik van PC's met ECC, en dat terwijl ik in de petro-chemie werk, waar veiligheid & betrouwbaarheid Nr 1, 2 en 3 is.

Want als een bedrijf als Shell, tegen HP zegt, we willen al onze PC's uitgevoerd met ECC, ze dat vast wel voor elkaar krijgen voor minder dan €50 per PC, dat is ruim genomen een extra TCO van €0.20 per week voor een PC die 5 jaar mee gaat, 'that's peanuts' vergeleken met de arbeidskosten voor een bedrijf als Shell, of bv banken.

Want als je kijkt naar de HP Microserver, is dat ECC helemaal niet veel extra hoeft te kosten, en toch vinden ze het niet noodzakelijk, en als je de originele prijs daarvan vergelijkt met een gewone office PC, dat de extra kosten waarschijnlijk ver onder de €50 zitten, en niet iets meer zijn dan het verschil tussen ECC en non ECC dat €1.5 per GB is.

En om CiPHER te quoten:

Verwijderd 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.

En in je eigen quote, zeg je het zelf al.

Q schreef op dinsdag 05 januari 2016 @ 20:09:
Dat is de befaamde Google-studie. Het is eigenlijk simpel. 8% van de geheugenreepjes heeft over de periode van een jaar op zijn minst 1 fout gezien. Een kans van ruwweg 1 op 13 dat een geheugen reepje dus een bit error zou zien. Stel dat de kans thuis wat kleiner is (de studie praat over zwaar belaste servers en bit fouten zijn gerelateerd aan de mate van belasting) dus maak de kans dan 1 op 130. Een factor 10 kleiner. Die silent data corruptie was dus 1 op ~1200.

Echter er is wel een punt: die 1 op 1200 gaat over een periode van 17 maanden = 1 jaar plus 5 maanden en die geheugen stats zijn per jaar. De stats voor silent data corruptie over 'slechts' een jaar zullen dus mogelijk nog wel positiever voor disks uitpakken.

Als je thuis geen ECC geheugen toepast dan weet je dus strikt genomen niet of je ooit door (tijdelijke) rotte RAM bits bent getroffen en of er nu data corrupt is. Net als dat je zonder ZFS niet weet of er misschien disk data corrupt is geraakt. Dat laatste was voor mij reden om ZFS te draaien als 'experiment'. Tot nu toe hebben zowel ECC geheugen als ZFS mij nog niet gered.

Als je dan nog eens bedenkt dat:

• Je thuis server minimaal een factor 50 minder I/O heeft, het zal voor vele waarschijnlijk zelfs een misschien zelfs wel een factor 1000 zijn.
• Je thuis server voornamelijk lees acties doet.
• Er een verschil is tussen permanente en tijdelijke corruptie

Als je dat mee rekent, dat je dan imho de gevaren zwaar overschat, en zoals CiPHER zegt, dat voor zakelijk tijdelijke corruptie funest is, terwijl voor thuisgebruikers vooral de permanente corruptie relevant is, en als ik de Nr's die we kunnen vinden op tel, zijn voor zover ik kan zien voor de meeste DIY NAS bouwers, de risico's zeker wel aanvaardbaar, en zijn jouw ECC aannames veel te veel gebaseerd op bedrijfsmodellen.

En zijn de voordelen van ZFS zelfs zonder ECC veel groter, dan jij doet voorkomen in je post.

[ Voor 5% gewijzigd door player-x op 13-08-2016 09:15 ]

[Q]

Player-X, het probleem is dat jij en anderen niet naar het probleem als geheel kijken maar selectief alleen het stukje wat jullie uitkomt er uit halen en dan roepen: ZFS is beter dan geen ZFS!

Waar jij met name over valt nu is dat ik de kans op geheugen fouten veel groter acht dan silent data corruptie vanuit het storage subsystem, waar ZFS tegen beschermt.
Maar er is meer dan voldoende informatie om dat hard te maken. En je kunt het zelfs beredeneren:

Een harde schijf zit vol met error correctie codes aan alle kanten, die dingen doen eigenlijk een fail-safe: ze 'falen veilig'. Of je krijgt data terug, of niet. Maar ze liegen bijna nooit.
Geheugen daarentegen is redelijk stabiel, maar bevat geen error detectie en correctie en de kans dat daar dus een keer een rotte bit doorheen floept, is dus veel groter. Er is geen vangnet.


Kans op geheugen flips in desktops

In een reguliere consumenten computer is het werkgeheugen zo'n beetje het enige component wat niet beschermd wordt door allerlei data integriteit checksums. Harde schijven offeren een flink deel van hun capaciteit op voor checksums. De communicatie protocollen zitten vol met checksums. Maar van werkgeheugen nemen we blind aan dat dit nooit foute informatie bevat.

Althans, voor desktops. Het risico van bitflips in RAM is zo ontzettend goed gedocumenteerd voor zowel desktops als servers dat ik niet snap dat er nog een discussie over is.

Hier is de Microsoft paper, kijk even naar de desktop stats:

https://www.microsoft.com...eurosys84-nightingale.pdf

Een kans van 1 op 1700 over een periode van 30 dagen dat je een bitflip ziet in slechts 1.5% van het RAM.

Ik ben geen wiskunde statistiek expert, maar volgens mij mag ik dit wel vertalen naar 1700 / (365 / 30) = 1 op 140. Dus een kans van 1 op 140 dat je in een jaar een geheugen fout meemaakt in slechts 1.5% van het RAM. Dus van iedere 140ste bezoekers hier op de site zal de computer 1 x per jaar een bitflip in dat stukje RAM zien.

Ik weet niet in hoeverre je kunt en mag extrapoleren vanaf die 1.5% RAM, maar het mag duidelijk zijn dat dan de risico's heel hard veel groter worden.

Leuke quote van de researchers van Microsoft:

Unfortunately, ECC memory is seen as a “premium” part, and is often used only in server machines. Field studies—such as ours—may observe many different environmental effects, such as dirt, heat, or assembly defects, all of which all can conspire to increase the probability of memory errors.

Computers thuis hebben het slechter dan in een datacenter met een constante temperatuur, luchtvochtigheid, afwezig van electromagnetische invloeden, etc.

Het enige grote en inderdaad belangrijke verschil is dat computers thuis meestal niet zo zwaar belast worden en de Google studie heeft aangetoond dat een hogere belasting de kans op geheugen fouten doet toenemen.

Dat een thuis server misschien wel een factor 1000 minder I/O ziet dan een 'echte' server maakt niet dat je het risico met een zelfde factor afneemt, dat is een drogredenering.
Bovendien, snij je jezelf enorm in de vingers, want met dat argument veeg ik dus ook direct de waarde van ZFS van tafel.

Geen ECC in desktops dus hoe belangrijk is ECC

Ik vind het jammer dat dit argument waarvan ik meende dat het al voldoende was bestreden toch weer op tafel wordt gegooid.

Binnen bedrijfsomgevingen is het niet zo'n punt dat desktops geen ECC geheugen bevatten omdat de gevolgen van een geheugen flip niet zo groot zijn.

Hooguit moet iemands desktop rebooten of ben je een paar minuten werk kwijt. Als het om een document op een netwerk schijf gaat is mogelijk een restore nodig (previous versions to the rescue).

Zelfs als een bitflip tot gevolg heeft dat een waarde in een document wordt aangepast waardoor verkeerde beslissingen worden genomen en de business schade groot is, dan is dat niets anders dan het equivalent dat een mens per ongeluk ergens een tikfout maakt. En bedrijven hebben meestal wel processen rond kritische informatie om te waarborgen dat de boel klopt.

Dat desktops geen ECC geheugen bevatten is ook anno 2016 meer een gevolg van het verleden en 'dat is hoe de markt is' dan dat het een hele bewuste keuze is. Je kunt niets afleiden uit het feit dat zelfs in kritische organisaties zoals Shell waarbij je het pand wordt uitgegooid als je de trapleuning niet vasthoudt toch desktops zonder ECC geheugen worden toegepast.

Kijk naar het totaalplaatje niet naar individuele componenten

Rekenvoorbeeld:

Risico op geheugen error per jaar: 5.0%
Risico op silent data corruptie op disk per jaar: 0.1%
Totale risico profiel voor data corruptie: 5.1%

Ga je nu wel ZFS toepassen maar geen ECC geheugen dan wordt het totale risico profiel 5.0%.
Een winst van 0.1% ofwel een verbetering van het risico profiel van wel - tromgeroffel - 2%.

Dus je risico profiel neemt slechts af met 2% en daarvoor moeten mensen dus wel Linux/BSD leren om ZFS te gaan draaien want dat is 'gratis' en het 'kost niets'?

Voor je totale risico profiel maakt die 2% vrijwel niets uit. Druppel op de gloeiende plaat.

Dit is waarom ik ZFS draaien zonder ECC-geheugen 'theater' noem.

Maar kijk nu wat er gebeurt als we het risico van non-ECC geheugen wegnemen.

Rekenvoorbeeld:

Risico op silent data corruptie op disk per jaar: 0.1%
Totale risico profiel voor data corruptie: 0.1%

Als we nu ZFS toepassen, dan nemen we dus zo'n beetje 100% van het risico profiel weg!

Dus nu gebrek aan ZFS de grootste blijvende risico factor is geworden, maakt toepassing van ZFS zeker uit en is het zinvol.

Hooguit kun je zelf er voor kiezen dat je het absolute risico van 0.1% dermate laag vind dat je het de moeite niet waard vind.

Zo komt ook mijn redenatie tot stand dat als je moet kiezen, dat je beter af bent met ECC geheugen en zonder ZFS dan vice-versa.

Mijn vraag is uiteindelijk: waarom draai je de achterdeur op slot en laat je de voordeur open staan?
Als je de voordeur open laat staan, dan kun je de achterdeur ook gerust open laten. Maakt voor het risico niets uit.

Pas als je het slot vervangt van de voordeur en deze op slot doet maakt het uit of je ook de achterdeur op slot zet.

Permanente vs tijdelijke corruptie

Er een verschil is tussen permanente en tijdelijke corruptie

De quote die je aanhaalt van CiPHER wordt direct gevolgd door mijn antwoord op deze discussie.
Het is een onjuiste voorstelling van zaken.

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.

Conclusie

Ik verwacht dat er wel weer discussies gaan ontstaan over de getallen in deze post. Het probleem is dat iedere keer die cijfers weer in twijfel worden getrokken, maar dat komt waarschijnlijk omdat ik er mee kom als ECC voorstander en ze goed in mijn argument passen.

Maar het probleem met de kritiek die ik hier heb is dat de argumenten altijd puur gericht zijn om onzekerheid te creëren in plaats van duidelijkheid te scheppen over wat de risico's echt zijn.

De stats komen allemaal uit Google / Amazon / Microsoft studies dus 'enterprise' en 'enterprise' is niet het zelfde als thuis. Natuurlijk is dat waar, maar dat is geen argument om dan maar de resultaten uit de 'enterprise' maar van tafel te vegen, wat nu gebeurt. Bovendien was die studie van Microsoft gericht desktops!

[ Voor 8% gewijzigd door Q op 13-08-2016 11:59 ]

[player-x]

Q schreef op zaterdag 13 augustus 2016 @ 11:29:
Risico op geheugen error per jaar: 5.0%
Risico op silent data corruptie op disk per jaar: 0.1%
Totale risico profiel voor data corruptie: 5.1%

Nu laten we jouw cijfers als feit nemen (het Google onderzoek zegt wat anders, en was die 1.5% sample van 2GB of 64GB), dan nog staan de cijfers aan de kant van dat het geen groot probleem is.

Want:

• je gebruikt geen 100% van je geheugen de hele tijd.
• De meeste R/W data zijn gewoon data, en geen checksum data, daarnaast is read data min of meer irrelevant, tenzij het gebruikt wordt voor een backup. (en ja ik weet dat de data ook gebruikt wordt voor die checksum's)
• Zelfs als er een stille fout optreed in een file, is de kans dat het in het file systeem zelf gebeurt veel en veel kleiner.
• En ZFS kan nog steeds een deel van die structuur fouten vinden waar ext4/NTFS dat niet kan.

Jij gaat uit dat je zo dicht mogelijk tegen 100% veiligheid aan wil zitten, terwijl de meeste mensen tevreden zijn als er geen data verlies optreed waar men hun hele series van baby foto's kwijt zijn, en als er toevallig een fotootje verloren gaat, dan is dat jammer maar nog niet het einde van de wereld voor ze, en daar voor geeft ZFS een grotere bescherming dan NTFS of ext4 dat doet.

Want je hebt "lies, damned lies and statistics", en het is maar hoe je het interpreteert, maar ik heb tot nu toe nog steeds geen onderzoek gezien wat de echte invloed en belang van ECC is op ZFS voor thuis gebruik.

[Q]

player-x schreef op zaterdag 13 augustus 2016 @ 12:56:
[...]

Nu laten we jouw cijfers als feit nemen (het Google onderzoek zegt wat anders, en was die 1.5% sample van 2GB of 64GB), dan nog staan de cijfers aan de kant van dat het geen groot probleem is.

1. Wat zegt Google volgens jou dan?
2. Heb je al in die microsoft paper gekeken? Daar staat het antwoord op je vraag (Verwacht je 64G RAM in een gemiddelde consumer desktop?)

Jij gaat uit dat je zo dicht mogelijk tegen 100% veiligheid aan wil zitten

Hoe rijm je die uitspraak met mijn consistente houding dat het volstrekt redelijk is voor mensen om gewoon een Synology of Qnap te kopen zonder ECC en ZFS en dat ze daarmee geen onredelijke risico's nemen?

Een Synology of Qnap is een 7.5 voor data veiligheid, een ECC + ZFS bouwsel een 9 wat mij betreft.
Als je met een 7.5 genoeg neemt, prima toch? Ook ruim voldoende.

], terwijl de meeste mensen tevreden zijn als er geen data verlies optreed waar men hun hele series van baby foto's kwijt zijn, en als er toevallig een fotootje verloren gaat, dan is dat jammer maar nog niet het einde van de wereld voor ze, en daar voor geeft ZFS een grotere bescherming dan NTFS of ext4 dat doet.

Volgens mij doe je alsof je het segment van mijn vorige post met die rekenvoorbeelden niet heb gezien.

Het feit dat ZFS tegen een risico beschermt wat NTFS/EXT4 niet kan is - als je naar de bredere context kijkt - irrelevant omdat je risico maar beperkt afneemt (2%).

Want je hebt "lies, damned lies and statistics", en het is maar hoe je het interpreteert, maar ik heb tot nu toe nog steeds geen onderzoek gezien wat de echte invloed en belang van ECC is op ZFS voor thuis gebruik.

Tja, precies zoals voorspeld, de getallen worden in twijfel getrokken, er wordt onzekerheid gezaaid. Maar zonder dat daadwerkelijk de moeite wordt genomen om dan een case te bouwen op basis van alle rapporten, zoals ik zelf wel meerdere keren heb getracht.

Maar die effort wordt weggewoven met esoterische what-if vragen die hooguit onzekerheid proberen op te roepen, een onzekerheid die er niet is.

Het klopt conceptueel gewoon niet dat je grote risico's laat liggen terwijl je wel moeite gaat stoppen om kleine risico's af te dichten. Als je logica volgt dan stop je ook geen specifieke moeite in het kleine risico.

Je dicht de kleinere risico's pas af als je de grotere risico's hebt afgedekt.

En daarmee besluit ik mijn betoog.

[player-x]

Q schreef op zaterdag 13 augustus 2016 @ 13:43:
Hoe rijm je die uitspraak met mijn consistente houding dat het volstrekt redelijk is voor mensen om gewoon een Synology of Qnap te kopen zonder ECC en ZFS en dat ze daarmee geen onredelijke risico's nemen?

Een Synology of Qnap is een 7.5 voor data veiligheid, een ECC + ZFS bouwsel een 9 wat mij betreft.
Als je met een 7.5 genoeg neemt, prima toch? Ook ruim voldoende.

Hier gaat imho je denk fout weer, alsof het de rest van de veiligheidswaarborgen van ZFS irrelevant zijn ten opzichte van NTFS/ext4 zonder ECC.

Daarnaast kan je, zoals ik altijd hebt gezegd, de gevaren van bitflips behoorlijk verkleinen, door je geheugen goed te testen.

Want als je je geheugen goed getest hebt, blijkt uit dat zelfde onderzoek, is die kans op bitflips enorm afgenomen, want DRAM geheugen werkt gewoon goed en blijft nagenoeg altijd gewoon goed werken, of je hebt een zo genoemde 'maandag morgen model' en dan neemt het risico enorm toe.

quote: Microsoft paper

One-bit DRAM failures
The middle two rows of Figure 2 show the crash probability for one-bit DRAM failures, which are broadly similar to the trends for CPU subsystem failures: The failure probability jumps by more than two orders of magnitude after a first failure is observed, and the probability further increases with subsequent crashes

Dit stukje van het onderzoek laat ook zien dat als er eenmaal een dimm is waar één bitflip heeft plaatsgevonden, dat de waarschijnlijkheid toe neemt dat het niet door externe invloeden plaats vond (kosmische radiatie bv), maar dat er een defect in het geheugen zit, dus als er meerdere errors plaats vinden, heb je gewoon geheugen met een slechte cel(len).

Maar dat toont ook aan als je je geheugen goed test, en er zijn geen problemen, dat de kans dan op bitflips significant kleiner zijn, en het imho een veel aanvaardbaarder risico worden.

Maar je focust geheel op het geheugen, alsof dat de "single point of failure'' is voor filesystemen, en dat terwijl ZFS veel meer waarborgen heeft dan alleen als je ECC gegarandeerd geheugen hebt.

De vijf functies als Copy-On-Write, silent error bescherming, snapshots, checksums, scrubbing, zijn de extra veiligheden die je een verhoogde veiligheid geven over NTFS/ext4, en bv ja op scrubbing heeft gegarandeerd geheugen een voordeel, maar dat neemt nog niet weg, dat scrubbing problemen zal vinden die NTFS/ext4 niet zou vinden.

Dus ja ECC verkleint ook de risico's bij die acties, maar jij doet net alsof zonder ECC ze opeens nutteloos worden, maar is dat echt zo?

Ik zie daardoor ZFS niet als 7.7 hebben, maar als een 8.5 hebben zonder ECC, en een 9 met ECC.

Als mensen een file systeem dat met een 8.5 ipv een 7.5 kunnen gebruiken, met hergebruikte hardware, dan zullen de meeste die 0,5 verloren veiligheid op de koop toe nemen om.
Daarnaast kan men later alsnog makkelijk overstappen op een nieuwe (zuinigere) mobo/CPU/ECC geheugen combo.

- En andere voordelen (die niet direct met veiligheid te maken hebben) zijn het makkelijk uitbreiden van storage space, toevoegen van pools met ZFS en disks met BtrFS en als laatste deduplication.
- De nadelen zijn uiteraard de leer curve om ZFS of BtrFS te gebruiken, ten opzichte van een kant en klare NAS of op Windows gebaseerde DIY NAS, en de kosten van extra verloren parity disks met ZFS.

[ Voor 11% gewijzigd door player-x op 14-08-2016 09:35 ]

[Q]

Roepen dat je met een geheugentest de risico's naar beneden haalt voor geheugen is gewoon zo erg, het is niet eens meer fout.

Ik denk dat mijn posts erg helder zijn geweest voor de mensen die hier komen lezen. Ik vertrouw er op dat ze verstandig genoeg zijn om zelf te bepalen wat wijsheid is. En uiteindelijk gaat het om hun data.

Het is conceptueel al lang al helder gemaakt waarom geheugen fouten meer kans hebben om te verschijnen dan silent data corruptie. De studies laten het zien en dankzij alle error correctie die al in de storage lagen zitten weten we hoe klein de kans is op silent data corruptie vanuit disk.

Je probeert te tornen aan de risico's door het risico van slecht geheugen te bagatelliseren en nut en noodzaak van ZFS op te krikken, maar dat strookt niet met de feiten.

Als je een significante stap wilt maken om je data te beschermen tegen silent data corruptie, dan is de eerste stap die zoden aan de dijk zet om ECC geheugen toe te passen. Pas als je dat hebt gedaan, wordt ZFS relevant. Dat heb ik hierboven gedemonstreerd met de 'berekening'.

Ik wil benadrukken dat ZFS draaien zonder ECC geheugen echt zonde van je moeite is als je dat doet om de reden 'het is veiliger'.

Stel je hebt drie machines die een bewerking doen op een product. Machine A, B en C.

Machine A = 10 onderdelen per uur
Machine B = 20 onderdelen per uur
Machine C = 15 onderdelen per uur

De doorvoersnelheid van de keten is helder: machine A is de flessenhals dus 10 onderdelen per uur.
Het mag voor de lezer dus duidelijk zijn dat als jij moeite stopt om machine C van 15 naar 20 onderdelen
per uur te upgraden, dat die effort NUL impact heeft op de doorvoersnelheid.

En daarom is het onzin om ZFS te draaien zonder ECC geheugen, je maakt het lokaal wel beter (machine C wordt sneller), maar voor het totaal plaatje verbetert je risico profiel niet.

Score voor data integriteit:

QNAP = 7.5
ZFS zonder ECC geheugen = 7.6
ZFS met ECC geheugen = 9

Ik besluit met liefde met een quote van Matthew Ahrens, co-founder van het ZFS project bij SUN:

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:

1. ECC geheugen
2. Checksumming file system.

Eerst ECC
Dan ZFS.

Ik dank u voor uw aandacht.

[ Voor 11% gewijzigd door Q op 14-08-2016 11:25 ]

[IceTeaGX]

Q schreef op zondag 14 augustus 2016 @ 11:17:
Stel je hebt drie machines die een bewerking doen op een product. Machine A, B en C.

Machine A = 10 onderdelen per uur
Machine B = 20 onderdelen per uur
Machine C = 15 onderdelen per uur

De doorvoersnelheid van de keten is helder: machine A is de flessenhals dus 10 onderdelen per uur.
Het mag voor de lezer dus duidelijk zijn dat als jij moeite stopt om machine C van 15 naar 20 onderdelen
per uur te upgraden, dat die effort NUL impact heeft op de doorvoersnelheid.

Ongeacht of de rest van uw argumentering juist is of niet, ga je hier toch volledig de mist in.
De vergelijking met een bottleneck raakt kant noch wal, er is namelijk geen correlatie tussen ECC geheugen en ZFS als filesystem. De ene zorgt er niet voor dat de andere meer of minder fouten maakt.

Stel eerder dat er een fout zit op de machines en ze een zeker percentage van de productie foutief doen:
Machine A = 5% per uur
Machine B = 20% per uur

ZFS is het gelijke aan machine A te verbeteren naar een 1% foutmarge.
Met ECC verlaag je de foutenmarge op machine B naar 1%

Uiteraard geeft ECC de beste verbetering in het gehele proces. Maar ZFS doet ook een op zich staande bijdrage, hoewel aanzienlijk kleiner
(of de verhoudingen nu juist zijn boeit me zo niet. het is een conceptuele weergave)

Ik heb niet moeilijk gedaan en beide gehanteerd, samen met een (veel te grote) UPS.
En ook ik ben een idioot, want ik gebruik een systeem (zfsguru/FreeBSD) dat ik onderliggend eigenlijk niet voldoende begrijp. Maar dan zitten we weer in een andere discussie.