ECC geheugen voor zelfbouw ZFS NAS?

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