ZFS und ECC-Ram

jmt

jmt

Well-Known Member
Hallo,

stimmt es eigentlich, dass ein ZFS-Pool durch Memory-Corruption unbrauchbar werden kann? Es gibt immer wieder Threads in den FreeBSD-Foren, die den Einsatz von ECC-Ram nahe legen. Welche "Gefahren" entstehen denn durch den Einsatz von normalen Speicher? Damit mein ich primär, ob die Auswirkungen schwerer wiegen als z.B bei UFS.

Danke Schon einmal für alle nützlichen Hinweise.:)
 
Ne, es geht nur darum, dass man den ganzen ZFS Checksummen (also die Mehr-Sicherheit gegenüber UFS) nicht vertrauen kann, wenn man seinem Arbeitsspeicher nicht vertrauen kann.

Kaputte Daten durch kaputten RAM bleiben kaputt, auch mit korrekter (aka kaputter) Checksumme.
 
Ok, aber habe ich dann z.B. eine Datei mit "defektem" Inhalt oder ist mein ganzer Pool hinüber? Erstes kann ich verschmerzen, letztes nicht.
 
Defekter RAM kann jedes Dateisystem zerschiessen...und gänzlich unbrauchbar machen. Das betrifft nicht nur ZFS.
Nur kommt es oft nicht so weit, weil meist vorher der Rechner schon einfach abschmiert oder fehlerhaft arbeitet.

Seit Version 28 von ZFS (aka FreeBSD 8.3 oder 9.0) können auch beschädigte Pools wieder eingehängt und gelesen werden...kompletter Datenverlust sollte mittlerweile also sehr unwahrscheinlich sein.
Aber ganz ausschließen kann man es nie...so lange defekte Hardware zwischenfunkt (gültig für alle Dateisysteme).
Deshalb macht man ja Backups!
 
jmt schrieb:
stimmt es eigentlich, dass ein ZFS-Pool durch Memory-Corruption unbrauchbar werden kann?
Zum Vergrößern anklicken....
Ja, ich habe mir durch Hauptspeicherkorruption einen Zpool unwiderbringlich zerschossen. Schon beim Versuch ihn zu importieren, gab es eine Panic. Sowohl unter FreeBSD, als auch unter OpenIndiana. ECC hätte mir allerdings nicht geholfen, da es ein defektes Kernelmodul war...
 
Wieso? Jedes Dateisystem wird dir irgendwann um die Ohren fliegen wenn du nur ordendlich Mist reinschreibst. Das hat nun mit ZFS nicht unbedingt was zu tun (wie ja schon berichtet wurde).

Vergleiche es mal mit nem Fahrrad. Ob du nun diese oder jene Reifen drauf packst ändert nichts an der Sicherheit des Ganzen wenn die Felgen total im Sack sind. Ob der Sturz nun mehr oder weniger weh tut hängt da halt auch bissl an deiner Vorsorge. (Auf dem Fahrrad wären das sinnvolle Klamotten und ein Helm, dein Dateisystem schützt du idealerweise mit Backups).
 
Meine Fragestellung geht eher in eine andere Richtung. Natürlich kann jedes Filesystem kaputt gehen. Weder bei UFS noch bei ext[2,3,4] oder xfs habe ich einen Totalausfall des Filesystems erlebt. Wenn ich Pech hatte, dann wurden ein paar Files zerstört oder sie fanden sich zerbröselt im "lost+found" wieder. Das alles passierte sehr selten. Selbst sterbende Festplatten ließen sich meist zu 99% auslesen. Es handelt sich hierbei für mich um ein überschaubares Risiko.
Bei ZFS hat es den Anschein, als ob solche Fehler gleich zu einem Totalausfall führen würden. Ist das der Fall, so wäre das Risiko eines Datenverlustes hier viel größer. Verhält sich ZFS aber analog den anderen FS, dann wäre der Einsatz relativ gefahrlos.

PS: Im möglichen Einsatzgebiet handelt es sich um viele Daten, für die ich bewusst kein Backup habe. Die Daten sind allesamt reproduzierbar, aber es wäre schon ärgerlich den Aufwand betreiben zu müssen. Deshalb versuche ich die Risiken abzuwägen.
 
jmt schrieb:
Hallo,

stimmt es eigentlich, dass ein ZFS-Pool durch Memory-Corruption unbrauchbar werden kann? Es gibt immer wieder Threads in den FreeBSD-Foren, die den Einsatz von ECC-Ram nahe legen. Welche "Gefahren" entstehen denn durch den Einsatz von normalen Speicher? Damit mein ich primär, ob die Auswirkungen schwerer wiegen als z.B bei UFS.

Danke Schon einmal für alle nützlichen Hinweise.:)
Zum Vergrößern anklicken....

Also, ich hab bisher... außer im Sun Cluster und bei defekter Hardware (Ausfall zweier WD Caviar Green nacheinander), noch keinen Pool verloren.

Mit ZFS auf Single Nodes kann ich aktuell sehr gut schlafen.

Mir ist es vor Jahren auch schon mal passiert das ein DB Server nach dem Stromausfall mit XFS, völlig zerbröselt war. Ob der Bug heute behoben ist? Nehme ich mal an, aber ich weiss es nicht.
Was ECC RAM angeht... normalerweise, wenn das OS und das ECC RAM Korrekt arbeitet, wird ein defektes Ram gebookmarked und als retired markiert. Sollte also nicht mehr genutzt werden.u

Da Computer und Software aber immer noch von Menschen gebastelt werden, wird es aber immer Fehlerquellen geben. Also ich kanns nur aus der Praxis sagen. ZFS ist mittlerweile Rockstable und ich möchte nicht mehr drauf verzichten müssen.
 
Danke für die Antwort, solarix. Was genau verstehst Du unter "Single Nodes" und verwendest Du durchweg ECC-Ram?
 
jmt schrieb:
Danke für die Antwort, solarix. Was genau verstehst Du unter "Single Nodes" und verwendest Du durchweg ECC-Ram?
Zum Vergrößern anklicken....

hi

single node bezieht sich hier darauf das es eine rechner mit platten und zfs ist
sprich kein cluster. ( sun hat , hatte eine cluster suite mit der man auch
storage hochverfuegbar machen kann , konnte. )

und yamagi ist vieleicht nicht unbedingt der masstab fuer normalen betrieb
so als freebsd developer ;)

holger
 
Dann muss ich vielleicht etwas ausholen: In der Maschine war eine Attansic / Atheros L1 NIC. Diese hat einen hardwarebug, durch den Daten statt in einen definierten Speicherbereich wirr irgendwo hin geschrieben werden, sofern dieser definierte Speicherbereich über 4GB liegt. Das war mir zu dem Zeitpunkt allerdings nicht klar. Er hatte ca. 16 Gigabyte Daten über das LAN empfangen, bevor es etwas kritisches im Hauptspeicher erwischt hat und die Kiste wunderbar abgeschmiert ist. Schon vorher hatte es wohl, von mir unbemerkt, den ZFS-Speicher getroffen, wodurch ZFS Müll in seinen Pool geschrieben hatte. Nach einem Reboot war der Pool im Eimer. Vielleicht hätte man ihn retten können (z.B. mit zdb(8)), aber ich hatte nach einem halbherzigen Rettungsversuch keine Lust mehr darauf, da die Daten fast totsicher auch beschädigt gewesen wären. Daher habe ich das Backup zurückgespielt und alles war gut. Mit UFS wäre das Dateisystem evtl. einfacher zu retten gewesen (lineare Dateisysteme sind praktisch unkaputtbar), allerdings die Daten ebenfalls im Eimer.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben