ECC geheugen voor zelfbouw ZFS NAS?

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

[player-x]

Q schreef op zondag 14 augustus 2016 @ 11:17:
Roepen dat je met een geheugentest de risico's naar beneden haalt voor geheugen is gewoon zo erg, het is niet eens meer fout.

Ooo, als fabrikanten het doen is het geen probleem, en heet het ''chips binning'', maar als we zelf controleren of we wel of geen goed non-ECC geheugen hebben is het nutteloos.

De cijfers van dat MS white paper geven toch echt aan dat als je een SDRAM chip hebt zonder problemen na een uitvoerige test, de kans aanzienlijk kleiner wordt dat je in de toekomst wel problemen zal krijgen, daar SDRAM in tegenstelling van NAND niet slijt

En in theorie mag je gelijk hebben van mij, in de praktijk is er een enorm verschil, maar zoals eerder gezegd, onze benadering van het probleem is geheel verschillend.

Heb het gevoel dat jij net als veel veiligheidsmensen die ik op werk tegen kom, teveel naar de theoretische problemen kijkt, en niet naar de uitkomst in de praktijk, en gevaren ziet waar ze niet zijn, en alleen naar de voor de hand liggende (vaak theoretische) problemen kijkt die ze hebben geleerd in opleiding veiligheidsdeskundige, en niet de verborgen gevaren.

Maar laten we het er maar weer over eens zijn dat we het oneens zijn met elkaar.

[Q]

De vergelijking met een bottleneck raakt kant noch wal, er is namelijk geen correlatie tussen ECC geheugen en ZFS als filesystem.

Dat is altijd het probleem met een analogie en je kritiek is hier terecht. Jouw betere voorbeeld toont op zijn minst aan dat mijn punt - wat ook in jouw voorbeeld zit - overkomt en dat is waar het mij om draait.

[Bardman01]

player-x schreef op vrijdag 12 augustus 2016 @ 07:01:
[...]

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.

Mijn nas/san (iscsi) nas4free met Raidz1 en 7 tb netto heeft nu 5 jr gedraaid op een toen nieuw mini ITX bordje van nog geeen 50 euro met 2GB men. Draait 24/7 in de trapkast headless uiteraard nul hd vervangen geen data corruption whatsoever . Heeft zonder een fout gedraait agelopen 5 jr drie keer een spannings uitval gehad waar ik 1 keer moest resilveren (automatisch) .

Zal niet representatief zijn maar voor mij reden genoeg om hier gewoon mee door te gaan. Ook de smart meldingen die je (kan) krijgen kunnen je gerust stellen.
De bordjes zijn niet meer verkrijgbaar dus dat ik dit soort discussies een beetje volg voor een eventuele vervanging en met welke hardware. Wat inmiddels meespeelt is het feit dat het zoveel data is (7 TB) en bijna vol je daar wel een paar dagen mee bezig bent om over te zetten en om die reden misschien ook beter is om thuis een wat 'beter 'systeem neer te zetten, en niet alleen maar grotere disks erin te zetten. Wat trouwens niet kan in een iscsi connection van Nas4free naar Windows.

[Q]

Bardman01 schreef op vrijdag 30 december 2016 @ 21:35 geen data corruption whatsoever .

Dat weet je dus niet zeker omdat je zonder ECC geheugen draaide. Silent data corruptie was dus nog steeds mogelijk.

[Brent]

Hangt beetje van het gebruik af: RO of RW? Als je checksummed, en vervolgens nooit meer naar het bestand schrijft (films of backups oid) dan weet je ook zonder ECC of er tussen maken checksum en teruglezen bitrot is geweest (je weet niet zeker of de checksum klopt met de oorspronkelijke data, immers precies op dat moment kun je een bitflip in je ram hebben). Cold storage dus, kun je wel wegkomen zonder ECC zou ik zeggen, of je maakt zelfs de checksums op een ECC systeem en je opslag-systeem kan dan zonder, dan weet je gegarandeerd dat de checksums kloppen.

(Her)schrijf je dagelijkse data, dan bereken je voortdurend opnieuw checksums en vergroot je dus de kans dat ram bitflips een effect hebben, en je verliest kennis over de integriteit over lange termijn (je weet dat het file wel of niet bitrot heeft tussen nu en T_checksum, en hoe minder ver in het verleden hoe minder je weet over lange termijn).

[Q]

Ook met cold storage loop je een risico. Op het moment dat je RAM geheugen data corruptie veroorzaakt, loopt al je data risico om verloren te gaan. Als data corruptie het file system zelf treft op de verkeerde plaats, ben je al je data kwijt.

Iedere write naar disk heeft onder deze omstandigheden de potentie om je file system corrupt te maken en dat betekent verlies van alle data, zeker met ZFS (niets ten nadele van ZFS!).

Voornamelijk read van data of een mix van read en write, het maakt niet uit. Dat moet niet de afweging zijn om al dan niet voor ECC geheugen te kiezen.

Ik ben het het met je eens dat minder writes = minder kans op file system corruptie, maar als je ZFS overweegt omdat je data blijkbaar zo belangrijk is, is dat dan werkelijk de afweging die je wilt maken?

Praat je dan over data integriteit in termen van 'er wel mee weg kunnen komen'?

Als je denkt weg te komen met non-ECC geheugen, dan kun je zeker ook zonder ZFS en dan is dit topic eigenlijk niet meer relevant voor je als lezer.

[FireDrunk]

Waarom ben je trouwens zo bang dat elke write potentieel je hele FS stoek maakt? Volgens mij hebben zowel BTRFS, Ext4, XFS, NTFS en ZFS meerdere superblocks?

De kans dat in zo'n korte tijd al je superblocks overschreven worden is vrij klein (is mijn perceptie, is niet berust op cijfers hoor).

Ik geloof best dat op het moment dat je bijvoorbeeld in een 'nacht' van kwaadaardige writes een paar superblocks naar de knoppen kan helpen, maar dat daarna eerder je FS op readonly gaat, of je een dikke kernel panic voor je kiezen krijgt, dan dat je hele OS kapoet gaat.

(Nou geloof ik bijvoorbeeld zeker wel dat bij iets als een scrub op kapot RAM, je je hele pool aan gort kan helpen, maar dat is volgens mij niet perse wat jij bedoelt).

Ik ben het absoluut niet met je oneens met je eens dat het potentieel kan hoor, maar om het nou direct een gevaar te noemen?

[Q]

Garbage in - garbage out.

Als je het superblock herberekend of enige andere file system metadata opnieuw berekent kan deze corrupt raken zonder dat je dit kunt observeren of er iets tegen kunt doen.

Wat heb je aan meerdere corrupte superblocks?

[ Voor 5% gewijzigd door Q op 03-01-2017 17:14 ]

[Brent]

Q schreef op dinsdag 3 januari 2017 @ 16:48:

Iedere write naar disk heeft onder deze omstandigheden de potentie om je file system corrupt te maken en dat betekent verlies van alle data, zeker met ZFS (niets ten nadele van ZFS!).

Praat je dan over data integriteit in termen van 'er wel mee weg kunnen komen'?

RO/RW, een wereld van verschil

[begintmeta]

Ik snap nog steeds niet dat applicaties niet zelf meer aan integriteitsbewaking doen Dan ben je van het hele gezeur (behoudens 'gezeur' over ECC-RAM zou je kunnen stellen) af.

[ Voor 18% gewijzigd door begintmeta op 03-01-2017 17:24 ]

[FireDrunk]

Nee hoor, want ook die soft-ecc (zoals ze dat noemen) kan ook fout gaan doordat je RAM stuk is.

[begintmeta]

Klopt, zoals ik ook al aangaf (al kan je de kans dat een random bitflip niet wordt opgemerkt softwarematig wel aanzienlijk verkleinen natuurlijk). Het punt is dat de applicatie sowieso de logische en fysieke integriteit moet bewaken, ECC is uiteraard altijd (als integriteit van belang is) nuttig. Een filesystem hoeft dan alleen de logische en fysieke integriteit van zijn eigen data (de metadata dus) te bewaken.

Maar dat dat met die applicaties niet zo werkt in de praktijk wordt denk ik wel bewezen door XFS dat ook maar data-checksumming lijkt te gaan krijgen.

[ Voor 12% gewijzigd door begintmeta op 03-01-2017 17:31 ]

[Brent]

begintmeta schreef op dinsdag 3 januari 2017 @ 17:29:
Klopt, zoals ik ook al aangaf (al kan je de kans dat een random bitflip niet wordt opgemerkt softwarematig wel aanzienlijk verkleinen natuurlijk). Het punt is dat de applicatie sowieso de logische en fysieke integriteit moet bewaken, ECC is uiteraard altijd (als integriteit van belang is) nuttig. Een filesystem hoeft dan alleen de logische en fysieke integriteit van zijn eigen data (de metadata dus) te bewaken.

Maar dat dat met die applicaties niet zo werkt in de praktijk wordt denk ik wel bewezen door XFS dat ook maar data-checksumming lijkt te gaan krijgen.

Checksums reken je uit in RAM, dus wil je ECC (of, je gokt erop dat RAM bitflips relatief weinig voorkomen en de rekentijd die je nodig hebt stevig onder de MTB bitflips zit).

Sowieso is dit een reden dat ik handmatig correctie toepas en opsla voor cold storage, zo hoef ik er niet op een fs checksum te vertrouwen, waarvan is zonder als RO te mounten nooit zeker weer of die achter mijn rug om herberekend wordt. Met je eigen checksums kun je in ieder geval weten of tijdens cold storage je bitrot hebt gehad, ongeacht RAM.

[begintmeta]

Brent schreef op dinsdag 3 januari 2017 @ 18:15:
[...]

Checksums reken je uit in RAM, dus wil je ECC (of, je gokt erop dat RAM bitflips relatief weinig voorkomen en de rekentijd die je nodig hebt stevig onder de MTB bitflips zit).

Zoals ik al aangaf: ECC is nuttig, maar softwarematig kan je de schade ook al wat beperken door bijvoorbeeld checksums meerdere keren uit te rekenen (wel inefficient natuurlijk), dat bij random bitflips dan elke keer dezelfde checksum zou resulteren, is weer wat minder waarschijnlijk.

Sowieso is dit een reden dat ik handmatig correctie toepas en opsla voor cold storage, zo hoef ik er niet op een fs checksum te vertrouwen, waarvan is zonder als RO te mounten nooit zeker weer of die achter mijn rug om herberekend wordt. Met je eigen checksums kun je in ieder geval weten of tijdens cold storage je bitrot hebt gehad, ongeacht RAM.

Wat mij betreft zou dus elke applicatie dat altijd moeten doen. (en dan liefst niet enkel detectie, maar ook correctie)

[Brent]

Sommige fileformats doen aan checksumming (compressieformaten bijv). Ik run af en toe mijn tooltje om de state of the disk te krijgen voor muziek/fotos, die natuurlijk geen checksums ingebouwd hebben.

[Q]

Zodra je van mening bent dat je data relevant genoeg is om checksums te gaan draaien, dan zou ik zelf zeggen: pas ECC geheugen en ZFS toe. Scheelt je een hoop gedonder en houdt alles simpel en geeft meer nachtrust. Maar dat moeten mensen natuurlijk uiteindelijk zelf weten

Ik vind het een aardig idee om een file system read-only te mounten maar als je ooit data wilt toevoegen dan loop je al weer risico als je geen ECC geheugen gebruikt. Resultaten uit het verleden bieden geen garantie voor de toekomst.

[FireDrunk]

Maar je kan in theorie wel 'rustig' scrubben op een read only filesystem. Zodra hij een mismatch ziet, zou je een melding of een statefile moeten krijgen. Dan kan je later een keer zeggen -> Pas alle 'scrub' acties toe.

Dat moet dan weer op een ander volume, en dat kan natuurlijk ook weer corrupt raken, maar goed.

(alsof je je par write acties even 'cached', en later pas toepast.)

[Brent]

Q schreef op dinsdag 3 januari 2017 @ 23:59:
Zodra je van mening bent dat je data relevant genoeg is om checksums te gaan draaien, dan zou ik zelf zeggen: pas ECC geheugen en ZFS toe. Scheelt je een hoop gedonder en houdt alles simpel en geeft meer nachtrust. Maar dat moeten mensen natuurlijk uiteindelijk zelf weten

Ik vind het een aardig idee om een file system read-only te mounten maar als je ooit data wilt toevoegen dan loop je al weer risico als je geen ECC geheugen gebruikt. Resultaten uit het verleden bieden geen garantie voor de toekomst.

Elke grote toko doet zelf checksums, want je wil eigenlijk ook weten wanneer die gemaakt is. Als jij nu scrubt, heb je geen flauw idee of net gister een virus alle eerste x bytes van al je files heeft overschreven of niet. Of user error, of weet ik wat. Ik wil graag zelf het moment van checksum vaststellen, en alleen updaten met mijn toestemming. Transport over ethernet of SATA resulteert ook in bitflips, en die zie je niet met een fs-level checksum.

FireDrunk schreef op woensdag 4 januari 2017 @ 07:40:
Maar je kan in theorie wel 'rustig' scrubben op een read only filesystem. Zodra hij een mismatch ziet, zou je een melding of een statefile moeten krijgen. Dan kan je later een keer zeggen -> Pas alle 'scrub' acties toe.

Dat zou mooi zijn idd. Mijn tooltje werkt met een aparte check- en correctiefase, juist omdat ik ook graag wil weten wanneer er flips zijn.

[FireDrunk]

Brent schreef op woensdag 4 januari 2017 @ 12:34:
[...]

Elke grote toko doet zelf checksums,

Heb je daar een bronnetje van?

[begintmeta]

Brent schreef op woensdag 4 januari 2017 @ 12:34:
...Transport over ethernet of SATA resulteert ook in bitflips, en die zie je niet met een fs-level checksum. ...

In hoeverre is bijvoorbeeld SATA-transport eigenlijk niet voorzien van foutdetectie/correctie?

[Brent]

begintmeta schreef op woensdag 4 januari 2017 @ 12:44:
[...]

In hoeverre is bijvoorbeeld SATA-transport eigenlijk niet voorzien van foutdetectie/correctie?

Die heeft het (per 8 bits heeft SATA 2 bits parity). Ook parity is echter geen garantie tegen flips, en zeker als je veel data verstouwt, loop je op een gegeven moment toch tegen die belachelijk kleine waarschijnlijkheden aan. Bovendien is het vervelende dat al die 'hard-ECC' scherpe randen hebben: zodra je chipset de data van je SATA kopieert naar de bus/interlink, vervalt de checksum van SATA en wordt die van je interlink berekent. Dan komt het aan in de CPU, die het naar je geheugen moved, en als je evt ECC ram hebt, weer een nieuwe checksum. Voor zover ik weet wordt er in de chips geen parity bijgehouden, en het wordt dus continue herberekend, dus long-term kun je niet achterhalen of er toch stiekem iets misging. Je vertrouwd blind op de hardware, en dat is iets dat ik liever niet doe

FireDrunk schreef op woensdag 4 januari 2017 @ 12:37:
[...]


Heb je daar een bronnetje van?

Het is een standaardtechniek in opslag, weet dus niet of men hier de moeite toe neemt. Backblaze is vrij open, je kunt daar eens browsen. Client-side tools als Dropbox en Owncloud bepalen aan de hand van checksums of het file is veranderd en geupload moet worden iig. S3 heeft een Content-MD5 header, die rekenen ze ook vast niet bij elke API request uit.

[Bardman01]

Q schreef op zondag 1 januari 2017 @ 01:26:
[...]


Dat weet je dus niet zeker omdat je zonder ECC geheugen draaide. Silent data corruptie was dus nog steeds mogelijk.

En wat is jou toevoeging in het hele verhaal? Want je geeft niet eens aan hoe ik dat eventueel zou moeten controleren. terwijl ik al aangegeven heb zonder problemen, en dus ook zonder data corruption 5 jaar heb gedraaid. Of moet ik me ook zorgen gaan maken over zaken die misschien en eventueel enz, zouden kunnen gebeuren...

Meteen maar 6 plankjes bestellen..?

[Q]

Bardman01 schreef op zondag 8 januari 2017 @ 12:28:
[...]


En wat is jou toevoeging in het hele verhaal? Want je geeft niet eens aan hoe ik dat eventueel zou moeten controleren.

Dat is juist het punt: je kunt het niet controleren. Dan had je continue van al je data checksums moeten maken op een andere machine ofzo, zoals hierboven ergens wordt gesuggereerd. Het is een conceptueel ding.

Daarom vind ik het ook zo zinloos dat mensen zich wel druk maken over ZFS maar dan ECC geheugen achterwege laten. Vanuit het perspectief van data integriteit is alleen ZFS toepassen betekenisloos. Aan het einde van de rit heb je nog geen zekerheid.

Kortom, hooguit kun je zeggen dat vanuit je storage-subsystem je geen data corruptie hebt meegemaakt. Maar dat verbaast me niets want de kans op silent data corruptie is extreem klein.

terwijl ik al aangegeven heb zonder problemen, en dus ook zonder data corruption 5 jaar heb gedraaid. Of moet ik me ook zorgen gaan maken over zaken die misschien en eventueel enz, zouden kunnen gebeuren...

Meteen maar 6 plankjes bestellen..?

Jouw persoonlijke ervaring is ook niets meer dan dat, een anekdote en een anekdote is geen bewijs.

Als ik je ervaring al ergens voor zou willen gebruiken dan zou het zijn om wederom aan te tonen dat storage erg betrouwbaar is en dat de kans op silent data corruptie heel erg klein is.

Brent schreef op woensdag 4 januari 2017 @ 12:34:
[...]

Elke grote toko doet zelf checksums, want je wil eigenlijk ook weten wanneer die gemaakt is. Als jij nu scrubt, heb je geen flauw idee of net gister een virus alle eerste x bytes van al je files heeft overschreven of niet. Of user error, of weet ik wat. Ik wil graag zelf het moment van checksum vaststellen, en alleen updaten met mijn toestemming. Transport over ethernet of SATA resulteert ook in bitflips, en die zie je niet met een fs-level checksum.

Ik weet niet precies waarom je dit schrijft. Ik zie je niet betwisten dat ECC plus ZFS een veel betere oplossing is om data integriteit te waarborgen dan het zelf proberen te realiseren met tooltjes en scriptjes te doen op non-ECC hardware.

Verder heb ik het idee dat je de goalpost aan het moven bent. Zowel ZFS als ECC beschermen niet tegen user-error of virussen. Natuurlijk kun je met ZFS snapshots, maar dat is echt out-of-scope. Dat heeft niets meer met ECC, of ZFS te maken.

De context van dit topic is de 'gewone' thuisgebruiker. Wat die grote toko's en jij doen is voor 99.99% van het publiek hier veel te ver gegrepen.

De essentie is dat RAM geheugen een van de weinige componenten is die niet met allerlei checksums wordt beschermt (tenzij je dus ECC gebruikt). SATA, Ethernet (TCP) alles wordt niet vertrouwd en zit onder de checksums.

Er kan nog steeds iets fout gaan, maar je druk maken over SATA / Ethernet maar niet over RAM, dan ben ik van mening dat de volgorde van de prioriteiten niet klopt.

Dat zou mooi zijn idd. Mijn tooltje werkt met een aparte check- en correctiefase, juist omdat ik ook graag wil weten wanneer er flips zijn.

Wat jij doet met je tooltje is leuk, maar voor 99.99% van het publiek hier niet realistisch.

[ Voor 40% gewijzigd door Q op 08-01-2017 23:12 ]

[Bardman01]

Q schreef op zondag 8 januari 2017 @ 18:45:
[...]


Dat is juist het punt: je kunt het niet controleren. Dan had je continue van al je data checksums moeten maken op een andere machine ofzo, zoals hierboven ergens wordt gesuggereerd. Het is een conceptueel ding.

Daarom vind ik het ook zo zinloos dat mensen zich wel druk maken over ZFS maar dan ECC geheugen achterwege laten. Vanuit het perspectief van data integriteit is alleen ZFS toepassen betekenisloos. Aan het einde van de rit heb je nog geen zekerheid.

Kortom, hooguit kun je zeggen dat vanuit je storage-subsystem je geen data corruptie hebt meegemaakt. Maar dat verbaast me niets want de kans op silent data corruptie is extreem klein.


[...]


Jouw persoonlijke ervaring is ook niets meer dan dat, een anekdote en een anekdote is geen bewijs.

Als ik je ervaring al ergens voor zou willen gebruiken dan zou het zijn om wederom aan te tonen dat storage erg betrouwbaar is en dat de kans op silent data corruptie heel erg klein is.


[...]


Ik weet niet precies waarom je dit schrijft. Ik zie je niet betwisten dat ECC plus ZFS een veel betere oplossing is om data integriteit te waarborgen dan het zelf proberen te realiseren met tooltjes en scriptjes te doen op non-ECC hardware.

Verder heb ik het idee dat je de goalpost aan het moven bent. Zowel ZFS als ECC beschermen niet tegen user-error of virussen. Natuurlijk kun je met ZFS snapshots, maar dat is echt out-of-scope. Dat heeft niets meer met ECC, of ZFS te maken.

De context van dit topic is de 'gewone' thuisgebruiker. Wat die grote toko's en jij doen is voor 99.99% van het publiek hier veel te ver gegrepen.

De essentie is dat RAM geheugen een van de weinige componenten is die niet met allerlei checksums wordt beschermt (tenzij je dus ECC gebruikt). SATA, Ethernet (TCP) alles wordt niet vertrouwd en zit onder de checksums.

Er kan nog steeds iets fout gaan, maar je druk maken over SATA / Ethernet maar niet over RAM, dan ben ik van mening dat de volgorde van de prioriteiten niet klopt.


[...]


Wat jij doet met je tooltje is leuk, maar voor 99.99% van het publiek hier niet realistisch.

Misschien moet je jezelf eens inlezen op ZFS, oa ook hier een kleine maar redelijk goede op tweakers te vinden in het Nederlands, zeer aan te raden. Negens in dat soort beschrijvingen ben ik een mandatory ECC tegengekomen voor ZFS.

Leuk dat je jezelf nog aangesproken voelt. en wederom niets toevoegd aan de discussie nas bouwen en ecc geheugen, behalve reacties van anderen aandragen die niet in mijn post staan en daar proberen argumenten mee te maken.

Nergens heb ik het over user fouten of virussen gehad dus onzin opmerking. enz.

Ook leuk dat je jezelf in deze post op punten tegen spreekt en argumenten erbij probeert te halen om de 'discussie' door te laten gaan.

Groet Brt
Maar helaas voor jou WOMBAT.

[Q]

Bardman01 schreef op woensdag 11 januari 2017 @ 17:12:
[...]


Misschien moet je jezelf eens inlezen op ZFS, oa ook hier een kleine maar redelijk goede op tweakers te vinden in het Nederlands, zeer aan te raden. Negens in dat soort beschrijvingen ben ik een mandatory ECC tegengekomen voor ZFS.

Leuk dat je jezelf nog aangesproken voelt. en wederom niets toevoegd aan de discussie nas bouwen en ecc geheugen, behalve reacties van anderen aandragen die niet in mijn post staan en daar proberen argumenten mee te maken.

Nergens heb ik het over user fouten of virussen gehad dus onzin opmerking. enz.

Ook leuk dat je jezelf in deze post op punten tegen spreekt en argumenten erbij probeert te halen om de 'discussie' door te laten gaan.

Groet Brt
Maar helaas voor jou WOMBAT.

Sorry ik snap niets van deze post, hij is niet eens in gramaticaal correct Nederlands geschreven.
Ik heb zelf meerdere artikelen geschreven over ZFS, heb je mijn signature gezien?

Verder doe je allemaal rare uitspraken over wat ik al dan niet heb geschreven, maar nergens toon je dit aan en laat je dit zien.

Dus tja.

[Brent]

Q is een beetje gevoelig, je bent niet de enige die dat opvalt Mijn code als scriptje afdoen is ook zo wat: het is duidelijk aangegeven dat het niet meer een hulpje voor par2 is, en forward-error-coding is heel fundamentele, oude en alomtegenwoordige techniek. De meeste moderne en wijdgebruikte clusterfses hebben een vorm van erasure coding in hun fundamentale opzet. bcachefs heeft t ook, en ik verwacht dat het gebruik ervan niet zal afnemen.

Niet dat ECC mem een simpele manier is om een deel van de processing-pipeline resistent(er) te maken, en ik zou het zeker doen voor een storage-oplossing, maar als je denkt dat je dan klaar bent, en die indruk werkt Q weleens, dan begrijp je het toch niet helemaal Maargoed, er is een verschil tussen iemand die clustertjes bouwt en mensen die wiskundige papers over FEC lezen (nofi Q, je vraagt erom). Ik weet nog dat storage mensen zfs onzin vonden, die zijn nu ook om. Uiteindelijk druppelen die dingen wel gewoon door, maar je moet wel even omhoog kijken

[ Voor 8% gewijzigd door Brent op 11-01-2017 18:55 ]

[begintmeta]

Brent schreef op woensdag 11 januari 2017 @ 18:53:
... maar als je denkt dat je dan klaar bent ...

Volgens mij ben je pas klaar als je zeker weet dat de data waar het om draait logisch en fysiek correct zijn, daarom vind ik het ook zo lastig om te ontkomen aan controle van de integriteit in de applicatie zelf. Zoals je ook eerder aangaf is het op de grensvlakken tussen de integriteitscontroles lastig na te gaan of de boel nog klopt, tenzij de integriteit mee wordt overgedragen, uiteindelijk komt het dus neer op de applicatie (of als je nog verder wilt gaan, in het brein van de gebruiker ervan)

Wat ik me op zich ook nog wel kan voorstellen is dat data nooit hun ruimte verlaten, en van die ruimte wordt de integriteit bewaakt. Applicaties werken binnen die ruimte en hoeven dan alleen nog de logische integriteit te bewaken.

[ Voor 17% gewijzigd door begintmeta op 11-01-2017 19:44 ]

[player-x]

Q schreef op woensdag 11 januari 2017 @ 18:05:
Sorry ik snap niets van deze post, hij is niet eens in grammaticaal correct Nederlands geschreven.

En hoe is dat relevant met de dingen die hij zegt, ik vind vallen over grammatica wel zo een beetje het domste tegen argument dat je kan bedenken.

Ik heb zelf meerdere artikelen geschreven over ZFS, heb je mijn signature gezien?

Hmmm, en zijn die door een peer review beoordeeld, de enige peer's die je beoordelingen hebben ge geven, over je meningen, zo ver ik kan zien, zijn vele hier op GOT, waar vele het gedeeltelijk of zelfs geheel oneens zijn met je.

Het enige dat het zegt is dat je ver gaande interesse in het onderwerp hebt, maar geeft je totaal geen krediet dat je een ZFS/ECC inwendig werkingsexpert ben.
IMHO ben je zelfs nog eigenwijzer dan ik, en wil je zelfs andermans argumenten niet zien.

Verder doe je allemaal rare uitspraken over wat ik al dan niet heb geschreven, maar nergens toon je dit aan en laat je dit zien.

Maar dat doe je zelf zelden of ook niet, behalven dan vaak cherry quoten, en misschien voelde hij zich daar niet toe geroepen om dat ook te doen.

quote: Q

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.

Dit is waar jij geloof ik voornamelijk je ECC evangelie op baseert.
Maar vaak laat je het tweede gedeelte weg, en als je het niet weg laat negeer je het min of meer.

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.

Letterlijk als je goed leest, het enige dat hij over ECC zegt is, en ja ik weet het is een probleem voor sommige, hij zegt is dat het slim is om ECC te gebruiken, en het is zelfs om het even wel file systeem je gebruikt.

En hij zegt het is slim om een checksum file systeem te gebruiken, en daar zegt hij niet over dat die speciaal samen met ZFS gebruikt moeten worden.

En de Google studie, quote je ook graag, welke imho stuk minder relevant is voor home NAS gebruikers, vanwege de totaal verschillende loads en gebruikspatronen.

Dus tja.

Dus...., Uh...., tja.............

[ Voor 8% gewijzigd door player-x op 11-01-2017 19:48 ]

[Brent]

begintmeta schreef op woensdag 11 januari 2017 @ 19:22:
[...]

Volgens mij ben je pas klaar als je zeker weet dat de data waar het om draait logisch en fysiek correct zijn, daarom vind ik het ook zo lastig om te ontkomen aan controle van de integriteit in de applicatie zelf. Zoals je ook eerder aangaf is het op de grensvlakken tussen de integriteitscontroles lastig na te gaan of de boel nog klopt, tenzij de integriteit mee wordt overgedragen, uiteindelijk komt het dus neer op de applicatie (of als je nog verder wilt gaan, in het brein van de gebruiker ervan)

par2, dat wat ik in mijn scriptje gebruikt, is helemaal ontworpen precies om die reden: het kan overal foutgaan, en reuze-interessant waar nou precies is het niet, het is interessant weer terug te kunnen naar een known state. Niet voor niets dat het vroeger en nog steeds een standaard was/is in verspreiding van software over newsgroepen: veel dataloss te verwachten op willekeurige locaties tijdens transport. Ben het met je eens dat idealiter erasure codes of tenminste een hash in elk format zou moeten zijn ingebakken, maar da's lastig. Zou trouwens interessant zijn daar een overzicht van te hebben, ik weet dat FLAC bijvoorbeeld crc32 opslaat. Misschien dat Word/Openoffice iets doen, want die formats zijn tegenwoordig gebaseerd op zip dacht ik, en dat kan ook checksums bijhouden.

Wat ik me op zich ook nog wel kan voorstellen is dat data nooit hun ruimte verlaten, en van die ruimte wordt de integriteit bewaakt. Applicaties werken binnen die ruimte en hoeven dan alleen nog de logische integriteit te bewaken.

Dat is op zich al interessant: heeft een cpu cache bijvoorbeeld ECC? Kan net zo goed een kosmisch straaltje langskomen. Zou de error rate dan moeten weten, dat zullen astronomische hoeveelheden vertrouwde data zijn en dus misschien best een grote kans .... Vind zogauw een analyse: http://www.ece.neu.edu/gr...publications/IEEETDSC.pdf
Ik geloof dat dit over een theoretische ECC cache gaat, weet niet of dat inmiddels al standaard is in Intel/AMD chips.

[tvwes]

Ik geloof dat de warme kerst gedachte in dit topic heeft plaats gemaakt voor een gure nucleaire winter wind.

Nu had ik eerder beloofd me hier buiten te houden maar mn vingers jeuken om nog digitale banden op het vuur te gooien.

uw toegewijde filesystem atheist

[FireDrunk]

Ja, CPU caches zijn al heeel lang voorzien van ECC. De nieuwste Intel netwerkkaarten hebben het ook al in de onboard buffers.

[Q]

Brent schreef op woensdag 11 januari 2017 @ 18:53:
Q is een beetje gevoelig, je bent niet de enige die dat opvalt Mijn code als scriptje afdoen is ook zo wat: het is duidelijk aangegeven dat het niet meer een hulpje voor par2 is, en forward-error-coding is heel fundamentele, oude en alomtegenwoordige techniek. De meeste moderne en wijdgebruikte clusterfses hebben een vorm van erasure coding in hun fundamentale opzet. bcachefs heeft t ook, en ik verwacht dat het gebruik ervan niet zal afnemen.

Niet dat ECC mem geen simpele manier is om een deel van de processing-pipeline resistent(er) te maken, en ik zou het zeker doen voor een storage-oplossing, maar als je denkt dat je dan klaar bent, en die indruk werkt Q weleens, dan begrijp je het toch niet helemaal

Klop, ik begrijp niet eens waar je tegen ageert, om heel eerlijk te zijn. Ik kan alleen zeggen dat voor de thuisgebruiker, voor wie een zelfbouw NAS meestal toch al een stap is boven een Synology/QNAP een par tool zoals jij hebt gemaakt een brug te ver is. Zo'n iemand zal veel eerder unraid oid gebruiken.

Ik zeg niet dat wat jij doet verkeerd is, maar het is voor de meeste mensen niet praktisch. En ook voor jouw tooltje geldt dat als je de checksums op non-ecc hardware berekent dat je eigenlijk nog een controle slag wil doen op een ander systeem, want anders ben je niet eens echt zeker of alles echt wel 100% ok is.

Maargoed, er is een verschil tussen iemand die clustertjes bouwt en mensen die wiskundige papers over FEC lezen (nofi Q, je vraagt erom). Ik weet nog dat storage mensen zfs onzin vonden, die zijn nu ook om. Uiteindelijk druppelen die dingen wel gewoon door, maar je moet wel even omhoog kijken

Een totaal andere context die totaal voorbij gaat aan de context van dit topic en dit forum en het publiek.

De context hier zou zijn dat mensen er op kunnen vertrouwen dat als ze bitjes aanleveren aan hun ZFS zelfbouw NAS dat die bitjes ook ongewijzigd op disk komen en weer worden opgehoest. Niets meer, niets minder. Met een leuk ZFS doosje met ECC geheugen kom je een heel eind en dat id goed genoeg en ook veel praktischer voor de meeste mensen dan jouw par tooltje. En dat bedoel ik niet negatief. Niets mis met je tool.

begintmeta schreef op woensdag 11 januari 2017 @ 19:22:
[...]

Volgens mij ben je pas klaar als je zeker weet dat de data waar het om draait logisch en fysiek correct zijn, daarom vind ik het ook zo lastig om te ontkomen aan controle van de integriteit in de applicatie zelf.

Inderdaad zou je dat het liefste willen zien end-to-end dataintegriteit controle. Maar dat is niet de praktijk en hoe de wereld werkt en dit valt buiten de scope van dit topic.

De scope hier is je NAS en dat de bitjes vanaf het moment dat ze de netwerkkaart binnen komen totaan het terug ophoesten redelijkerwijze vertrouwd mag worden. En zonder ECC geheugen en zoiets als ZFS kun je dat niet waarborgen.

player-x schreef op woensdag 11 januari 2017 @ 19:28:
[...]

En hoe is dat relevant met de dingen die hij zegt, ik vind vallen over grammatica wel zo een beetje het domste tegen argument dat je kan bedenken. [

Misschien kan jij het me uitleggen wat hij/zij bedoeld?

Hmmm, en zijn die door een peer review beoordeeld, de enige peer's die je beoordelingen hebben ge geven, over je meningen, zo ver ik kan zien, zijn vele hier op GOT, waar vele het gedeeltelijk of zelfs geheel oneens zijn met je.

Het enige dat het zegt is dat je ver gaande interesse in het onderwerp hebt, maar geeft je totaal geen krediet dat je een ZFS/ECC inwendig werkingsexpert ben.

Ik denk dat jij mijn motivatie van die links van mij naar mijn eigen site verkeerd interpreteert. Ik wil er zeker niet mee pretenderen expert te zijn van ZFS inwendig zelf, ik claim zeker geen authoriteit te zijn. ik wil alleen aantonen dat ik wel een beetje ben ingelezen.

IMHO ben je zelfs nog eigenwijzer dan ik, en wil je zelfs andermans argumenten niet zien.

Oh de ironie

Dit is waar jij geloof ik voornamelijk je ECC evangelie op baseert.
Maar vaak laat je het tweede gedeelte weg, en als je het niet weg laat negeer je het min of meer.

Your honour I present exhibit A, a quote form a comment written by me as a reply to a visitor. In this quote I present evidence that I'm not guilty as claimed and that I acknowledge that both ZFS and other file systems are at risk.

http://louwrentius.com/pl...y.html#comment-2711566425

I must say I disagree, ECC is required if you want 'absolute' data integrity. ECC has nothing to do with ZFS specifically. If you want a stable NTFS, EXT4 or XFS based system (with MDADM), the same rule applies, if you really care about your data, use ECC memory.

Ik ben het eens met dat stukje tekst in de quote van Matthew.


ZFS heeft geen ECC nodig. Maar als je geeft om data-integriteit dan heb je per definitie ECC geheugen nodig

Letterlijk als je goed leest, het enige dat hij over ECC zegt is, en ja ik weet het is een probleem voor sommige, hij zegt is dat het slim is om ECC te gebruiken, en het is zelfs om het even wel file systeem je gebruikt.

Mee eens!

En hij zegt het is slim om een checksum file systeem te gebruiken, en daar zegt hij niet over dat die speciaal samen met ZFS gebruikt moeten worden.

Ook mee eens!

Hij legt heel duidelijk een accent dat de prioriteit in eerste instantie bij ECC geheugen ligt. en dan additionally dat het ook verstandig is om een file system te gebruiken dat je data checksummed, zoals ZFS.

En dat is precies mijn standpunt.

1. ECC geheugen
2. ZFS / BTRFS / ReFS (tip: kies ZFS )

En ik heb hier boven meerdere malen proberen te argumenteren waarom dat zo is.

Het punt is dat je storage sub-system al ondergesmeerd is met ECC/Parity overal[1]. De kans op silent data corruptie is enorm klein. Dat heb ik ook in mijn artikelen beargumenteerd. RAM geheugen is juist de zwakste schakel, een van de weinige plekken die op geen enkele wijze wordt beschermd.

[1] Consumenten SATA schijven hebben een cache geheugen dat geen ECC doet, in tegen stelling tot enterprise schijven. (nuance)

En de Google studie, quote je ook graag, welke imho stuk minder relevant is voor home NAS gebruikers, vanwege de totaal verschillende loads en gebruikspatronen.

Heb je ook nog iets te zeggen over die Microsoft studie die met desktop machines laat zien hoeveel risico je loopt?

Kijk even naar voetnoot 4.

http://louwrentius.com/pl...ecc-memory.html#fn:mstudy

[ Voor 57% gewijzigd door Q op 11-01-2017 22:55 ]

[Brent]

Q schreef op woensdag 11 januari 2017 @ 21:06:
[...]

Ik zeg niet dat wat jij doet verkeerd is, maar het is voor de meeste mensen niet praktisch.

Je kunt dit blijven herhalen, maar toch is er een universum aan mensen dat dagelijks par2 draait over hun data. Om het over TafoeFS (zfec) en bcachefs maar niet te hebben. Q, het zou helpen als je niet alles wat jij denkt dat typisch gebruik is wegzet als marginaal. Wij mogen er toch andere wensen op nahouden dan jij, niet?

[player-x]

Q schreef op woensdag 11 januari 2017 @ 21:06:
Hij legt heel duidelijk een accent dat de prioriteit in eerste instantie bij ECC geheugen ligt.

Ik zou als ik jouw was toch nog maar eens die quote goed lezen, want ik lees er niet in dat hij zegt ECC is prio1, alleen dat hij het belangrijk vind.

Ik geloof van me zelf dat ik iets boven gemiddeld begrijpend kan lezen, maar ik lees er iig niet in wat Q hier zegt, andere die het hier met mij eens/oneens zijn?

Heb je ook nog iets te zeggen over die Microsoft studie die met desktop machines laat zien hoeveel risico je loopt?

Kijk even naar voetnoot 4.

http://louwrentius.com/pl...ecc-memory.html#fn:mstudy

Yep gelezen, en het toont aan dat ongeveer 1 in 1700, er brakke geheugen setjes tussen zitten, en een goede lange geheugen burn-in test kan daar de meeste van vinden, en ook een uitgebreidere mem test tijdens op/re-starten kan behoorlijk het risico verlagen.

Zou ik dit adviseren voor missie critcal systemen, absoluut niet, maar veel mensen zullen zeggen, 1:1700, en 1:+25.000? na een goede burn-in test, daar kan hij best mee leven, als hij zijn oude hardware kan her gebruiken, want zo groot is bij iedereen niet het budget als bij jouw of mijn +€3000,-- server's.

voor nieuw koop scheelt het niet veel meer en is het dom om niet te nemen, maar voor hergebruik scheelt gewoon minimaal €200, en dat is voor veel mensen nog steeds een hoop geld

En voor die mensen is ZFS dan nog steeds een stuk veiliger dan NTFS en ext4, en als ze later wel het geld hebben, dan kunnen ze alsnog een mooi ECC systeempje bouwen, en hun HDDs over zetten.

Want ZFS zelfs zonder ECC is nog steeds een stuk veiliger dan NTFS/ext4 zonder ECC, dat je dat niet wil zien met je starre houding, worden een hoop mensen ge-irriteert van je.

[Q]

Brent schreef op woensdag 11 januari 2017 @ 23:29:
[...]
Je kunt dit blijven herhalen, maar toch is er een universum aan mensen dat dagelijks par2 draait over hun data. Om het over TafoeFS (zfec) en bcachefs maar niet te hebben. Q, het zou helpen als je niet alles wat jij denkt dat typisch gebruik is wegzet als marginaal. Wij mogen er toch andere wensen op nahouden dan jij, niet?

Ja hoor.

Maar wat is er mis met marginaal, dat slechts een kleine groep mensen iets doet wil niet zeggen dat het slecht is, maar dat het misschien alleen geschikt is voor wat meer technisch onderlegde mensen.

Ik denk dat jouw par2 tool niet echt de juiste oplossing is voor de doorsnee gebruiker, iemand die lang niet jouw kennis en kunde heeft.

player-x schreef op donderdag 12 januari 2017 @ 00:00:
[...]

Ik zou als ik jouw was toch nog maar eens die quote goed lezen, want ik lees er niet in dat hij zegt ECC is prio1, alleen dat hij het belangrijk vind.

Tja 'in addition' betekent toch echt 'als toevoeging' (dus als extra (bovenop)). Dus het fundament is ECC geheugen.

Yep gelezen, en het toont aan dat ongeveer 1 in 1700, er brakke geheugen setjes tussen zitten,

Je hebt niet alles gelezen blijkbaar.

A consequence of confining our analysis to kernel code pages is that we will miss DRAM failures in the vast majority of memory. On a typical machine kernel code pages occupy roughly 30 MB of memory, which is 1.5% of the memory on the average system in our study. since we are capturing DRAM errors in only 1.5% of the address space, it is possible that DRAM error rates across all of DRAM may be far higher than what we have observed.]

Dus de kans op een rotte plek in je geheugen is veel groter omdat ze 1 in 1700 hebben geobserveerd in slechts 1.5% van de totale beschikbare hoeveelheid geheugen.

Dus daar gaat je betoog.

en een goede lange geheugen burn-in test kan daar de meeste van vinden, en ook een uitgebreidere mem test tijdens op/re-starten kan behoorlijk het risico verlagen.

Roepen dat je met een geheugentest de risico's naar beneden haalt voor geheugen is gewoon zo erg, het is niet eens meer fout.

Geen gebruiker op dit forum zal een volledige memtest doen iedere keer bij het booten. Jij bent misschien de enige.

Zou ik dit adviseren voor missie critcal systemen, absoluut niet, maar veel mensen zullen zeggen, 1:1700, en 1:+25.000? na een goede burn-in test, daar kan hij best mee leven, als hij zijn oude hardware kan her gebruiken, want zo groot is bij iedereen niet het budget als bij jouw of mijn +€3000,-- server's.

Dataveiligheid kost geld en als je dat geld er niet voor over hebt tja, dan loop je risico en dat moet je onderkennen.

voor nieuw koop scheelt het niet veel meer en is het dom om niet te nemen, maar voor hergebruik scheelt gewoon minimaal €200, en dat is voor veel mensen nog steeds een hoop geld

Mensen willen gewoon niet accepteren dat data-integriteit gewoon geld kost.

En voor die mensen is ZFS dan nog steeds een stuk veiliger dan NTFS en ext4, en als ze later wel het geld hebben, dan kunnen ze alsnog een mooi ECC systeempje bouwen, en hun HDDs over zetten.

Dat is dus onzin.

Als mensen geen ECC toepassen dan maakt het niet uit wat voor file system ze draaien: je prioriteit ligt dan niet meer bij data-integriteit.

Als dat het geval is, dan is het prima als een QNAP kopen, of MDADM draaien met EXT4, of XFS, of ZFS. Maar ZFS voegt niets toe voor die mensen. Ik zou mensen ZFS niet ontraden, maar er is geen reden voor die mensen om specifiek ZFS te draaien. Ze kunnen zich dan veel beter richten op wat het beste bij ze past in termen van kennis niveau en vaardigheden en in hoeverre ze tijd in zaken willen stoppen.

Ik pak er nog even een mooie quote van jou bij:

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.

Wat jij hier nu schrijft houdt in dat de meeste mensen dus in jouw beleving prima af zijn zonder ECC geheugen en zonder ZFS.

Als mensen het accepteren dat er toevallig een fotootje verloren gaat dan accepteren ze bepaalde risico's en dan hoeven die mensen echt geen ZFS te draaien (of ECC geheugen toe te passen).

Het is irrationeel om een risico af te dekken wat je toch al accepteert.

[Bardman01]

Q schreef op woensdag 11 januari 2017 @ 18:05:
[...]


Sorry ik snap niets van deze post, hij is niet eens in gramaticaal correct Nederlands geschreven.
Ik heb zelf meerdere artikelen geschreven over ZFS, heb je mijn signature gezien?

Verder doe je allemaal rare uitspraken over wat ik al dan niet heb geschreven, maar nergens toon je dit aan en laat je dit zien.

Dus tja.

Aantonen? begin daar zelf eens mee want dat was de reden dat ik reageerde op jou. De tegenstellingen en aanhalingen van anderen om maar een argument te hebben staat gewoon in jou eigen post dus wat moet ik nog aantonen. En grammaticaal pfft.

Wat ik eerder al zei WOMBAT.

[Q]

Waste of Brains Money and Time. Nieuwe term geleerd

Ik heb nog even terug gelezen waar onze conversatie over ging. Ik zie dat je reageerde op een opmerking van mij over virussen en user error die niet aan jou gericht was maar aan iemand anders, dus vanuit jouw context gezien begrijp ik de verwarring.

[ Voor 70% gewijzigd door Q op 12-01-2017 11:58 ]