BSD/UnixBSD/UnixZFS - utvide et pool med nytt vdev?

[jonny]

Litt sent ute, men jeg ser ikke at mangel på ECC skal gjøre ting verre ved bruk av ZFS sammenlignet med andre filsystemer. Selvfølgelig, hvis det er noe alvorlig galt med minnet slik at det skjer mange feil på kort tid kan det bli riktig galt, men det fører ofte til andre problemer også - som programkrasj, bluescreens osv.

 

Hvis det blir feil i minnet fordi et eller annet bit plutselig bytter verdi en sjelden gang, og tilfeldigvis dette bit'et var i data ZFS skal skrive til disk eller nettopp har lest fra disk, vil ZFS regne ut ny sjekksum og skrive dataene til disk med en slik gal bit. Akkurat det samme ville skjedd med et annet filsystem, bortsett fra at ZFS sjekker dette også ved lesing og vil dermed også "rette opp" til feil verdi på disken da.

 

Hvor ofte en slik tilfeldig bit-feil vil forekomme avhenger sikkert av mange faktorer, men jeg tror nok de er relativt sjeldne. Det er nok mye større sannsynlighet for at en "scrub"-sesjon på 24 timer med 16GB minne går uten at en slik bit-feil skjer enn det motsatte :-)

 

Når det er sagt bruker jeg selv ECC-minne der jeg bruker ZFS, da det gir absolutt best magefølelse.

 

Edit: Jeg vet heller ikke hvordan ZFS håndterer en slik feil, om dataene leses på nytt fra disk og skrives til et annet område i minnet vil det jo kunne gå greit. Hvis det er data som skal skrives til disk vil en slik minnefeil uansett føre til at feilen blir skrevet til disk.

Endret 5. august 2014 av jonny

[endrebjo]

Litt sent ute, men jeg ser ikke at mangel på ECC skal gjøre ting verre ved bruk av ZFS sammenlignet med andre filsystemer. Selvfølgelig, hvis det er noe alvorlig galt med minnet slik at det skjer mange feil på kort tid kan det bli riktig galt, men det fører ofte til andre problemer også - som programkrasj, bluescreens osv.

 

Hvis det blir feil i minnet fordi et eller annet bit plutselig bytter verdi en sjelden gang, og tilfeldigvis dette bit'et var i data ZFS skal skrive til disk eller nettopp har lest fra disk, vil ZFS regne ut ny sjekksum og skrive dataene til disk med en slik gal bit. Akkurat det samme ville skjedd med et annet filsystem, bortsett fra at ZFS sjekker dette også ved lesing og vil dermed også "rette opp" til feil verdi på disken da.

 

Hvor ofte en slik tilfeldig bit-feil vil forekomme avhenger sikkert av mange faktorer, men jeg tror nok de er relativt sjeldne. Det er nok mye større sannsynlighet for at en "scrub"-sesjon på 24 timer med 16GB minne går uten at en slik bit-feil skjer enn det motsatte :-)

 

Når det er sagt bruker jeg selv ECC-minne der jeg bruker ZFS, da det gir absolutt best magefølelse.

 

Edit: Jeg vet heller ikke hvordan ZFS håndterer en slik feil, om dataene leses på nytt fra disk og skrives til et annet område i minnet vil det jo kunne gå greit. Hvis det er data som skal skrives til disk vil en slik minnefeil uansett føre til at feilen blir skrevet til disk.

Den teoretisk mulige selvdestruktive mekanismen er beskrevet her, og sammenlikner samtidig med hva som ville skjedd i et ikke-ZFS-system.

Problemet bunner ut i at korrupt minne i ZFS vil generere falske positiver pga valideringen som skjer når data blir lest fra disk. Disse falske positivene vil ZFS prøve å fikse automatisk, og kan dermed ende opp med å gjøre mer skade enn det i utgangspunktet var.

[siDDis]

Nei, det er ikkje riktig. Får du false positive, så vil ZFS framleis sjekke andre nivåer av metadata for å forhindre nettopp dette. ZFS har nemleg checksumming av metadata per inode også heilt opp til rot, og rot har vell 3 duplikater igjen.

 

Sjølvsagt er det betre med ECC minne, men at ZFS må ha ECC minne og det er farleg utan ECC minne er bullshit.

 

EDIT:

Legger ved kommentar frå ein av utviklerane til ZFS

http://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26303271#p26303271

Endret 29. mai 2015 av siDDis