Thread Starter
- Mitglied seit
- 27.08.2002
- Beiträge
- 4.276
Im Aufbau.
Was sind denn die Probleme um die man sich kümmern muss?
Worum geht es bei dem Thema im Kern?
Warum eigentlich ECC RAM?
Wann brauche ich ein Backup trotz Raid?
Worauf muss ich bei ECC Speicher achten?
Gibt es unterschiedliche Arten von ECC?
Kann mir nicht jemand das lesen abnehmen?
Warum eigentlich ECC RAM?n4
Zitat von Holt
"Desktopplatten in ein NAS zu bauen würde ich niemandem empfehlen, schon gar nicht bei einem 4 Bay NAS. Hinterher taugen natürlich dann die Platten nichts, wenn die das nicht lange mitmachen
Aufwand bei Einrichtung und Wartung hast Du bei einem Fertig-NAS auch, der ist bei einem System wie OMV, welches eine fertige Distribution von einem Debian Linux für NAS Anwendung ist, nicht wirklich höher.
Erstens hat auch das DS716+ die Prüfsummen nur zur Erkennung und nicht auch Korrektur bei Fehlern aktiviert und zweitens ist das auch gut so und verantwortungsvoll. Das DS716+ hat nämlich genauso wenig ECC RAM wie das DS415+, wobei es beim DS415+ wirklich unverständlich ist, da dessen Atom C2538 sogar ECC RAM unterstützen würde, man hat nur eben keines verbaut, weil die NAS Hersteller diese Feature nur den ganz teuren Kisten spendieren.
Filesysteme mit Fehlerkorrektur über Prüfsummen sind aber ohne ECC RAM nicht nur Schwachsinn, sondern sogar gefährlicher Blödsinn. Schwachsinn ist es, weil HDDs praktisch nie falsche Daten rückliefern, die liefern dann einen Lesefehler und keine korrupten Daten, wenn die Daten eines Sektors nicht zur ECC dahinter passen. Das dies unerkannt bleibt, also die Daten falsch sind und trotzdem zur ECC passen, ist so gut wie ausschlossen. Die Übertragung über SATA wird ebenfalls abgesichert, da gibt es eine CRC32 hinter jedem FIS, also jedem Übertragungspaket welches bis zu 8192 Bytes Nutzdaten haben kann und das reicht um nur etwas weniger als einen von 10^40 Fehler nicht zu erkennen, das mal 8k ist ein Datenvolumen größer als das Internet und da man Ultra-DMA Fehler wegen der Verzögerung bei der Übertragung und in den S.M.A.R.T. Werten sowieso erkennt, sollten die sowieso behoben werden, also praktisch dürfte wohl noch nie ein Fehler bei der SATA Übertragung unbemerkt geblieben sein.
Damit bleiben nur Fehler auf den internen Datenpfaden oder Fehler aufgrund von FW Bug der Platte oder des Host Controllers die so eine Prüfsumme erkennen kann und die man sonst nicht durch Lesefehler von der Platte erkannt hätte. Solche Lesefehler sind bei einem funktionierenden echten RAID (also kein RAID 0) dann aber auch kein Problem, da über die Paritydaten die Daten rekonstruiert und wieder auf die Platte mit dem Fehler geschrieben werden. Nur dann liest ein normaler Linux SW RAID überhaupt mal die Paritydaten aus. Ein FS mit Prüfsummen liest die immer (geht auf die Performance) und meldet jeden Fehler, nur wenn der Fehler im RAM passiert ist weil eben kein ECC RAM verwendet wird, denn gibt es mindestens mal einen Fehlalarm das eine Datei korrupt sein.
Wird nun aber auch die Fehlerkorrektur verwendet und die Paritydaten bzw. Prüfsumme ist gerade in dem RAM Bereich wo ein Fehler vorliegt, denn wird es schnell kritisch, diese Filesysteme trauen ihren Prüfsummen nämlich mehr als den gelesenen Daten und korrigieren den vermeidlichen Fehler und schreiben die nun kaputtkorrigierten Daten zurück. Bei einem hard-error der RAMs, also einem wiederholt an bestimmten RAM Adressen bei stimmten Bitmustern auftretenden Fehler, frisst sich der Fehler dann wie ein Krebs durch die Daten und wenn die Metadaten betroffen sind, ist der Pool kaputt und mit Pech hat man die korrupten Daten schon auf dem Backup. Berichte von Leute denen sowas mit ihren ZFS Pools auf Consumer-HW ohne ECC passiert ist, finden sich zu genüge im Netz.
Dagegen ist das was bei einem Linux md SW-RAID bei RAM Fehlern passiert geradezu harmlos, denn die RAID sind ja nicht auf zugleich Filesysteme, wie eben ZFS und BTRFS, die beides sind, RAID und Filesystem. Auf einem md-RAID kann man jedes Filesystem verwenden, die Daten des Filesystems werden vom darunter liegen Layer des RAIDs daher auch nie geändert, außer eben bei der oben beschrieben Rekonstruktion, aber die ändert ja auch keine Daten. Gibt es hier einen RAM Fehler, werden die Daten oder die Parity falsch geschrieben, sind die Daten betroffen war es das, aber bei ZFS oder BTRFS ist das nicht anders, wenn die Daten von der Netzwerkkarte kommen und in einem RAM Bereich mit einem Fehler landen, werden die vom Filesystem auch schon verändert gelesen, die Prüfsumme wird über die korrumpierten Daten gebildet und der Fehler ist permanent, man fühlt sich nur in der falschen Sicherheit sie wären korrekt.
Wird beim md SW-RAID die Parity falsch geschrieben, werden die Daten nur in dem Fall korrupt, wenn dann auch in dem betroffenen Bereich ein Lesefehler passiert und Daten rekonstruiert werden müssen, was ja nun auch nicht so oft auftritt. Die RAM Fehler haben da also weniger gravierende Auswirkungen, auch wenn sie ebenfalls das Filesystem korrumpieren können, wenn Metadaten betroffen sind und in jedem Fall können die Nutzerdaten unbemerkt korrupt sein, wenn diese Veränderung eben vor dem Schreiben im RAM passiert ist, nur wiegt man sich eben nicht in einer falschen Sicherheit.
Man sollte es mit Matt Ahren halten, einem der Mitentwickler von ZFS und der rat dazu zu aller erst einmal ECC RAM und natürlich ein passendes System welches dieses auch unterstützt zu verwenden, wenn man seine Daten liebt:
Besonders gerne missverstanden wird übrigens dieser erste Teil seines Posts aus dem das Zitat stammt: Die eigentliche Aussage des Satzes habe ich mal hervorgehoben, aber weil eben Filesysteme wie NTFS oder ext gerne auf Desktops ohne ECC genutzt werden, versuchen viele darauf abzuleiten man könnte dies auch genauso gut mit ZFS machen, weil ja nichts bei ZFS speziell nach ECC RAM verlangt was es bei anderen Filesystemen nicht auch tun würde. Richtig ist aber und das wird ja auch im Satz "if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data" klar, dass kein System ohne ECC RAM sicher für die Daten ist und man beim ECC RAM eben anfängt, dann erst lohnt es überhaupt erst sich um Prüfsummen Gedanken zu machen aber eben nicht umgekehrt. Ohne ECC RAM ist es dann auch egal ob man ein Filesystem mit Prüfsummen hat oder nicht.
Das der erste Teil "There's nothing special about ZFS that requires/encourages the use of ECC RAM" so nicht ganz stimmt, habe ich ja schon erklärt, aber er wird sein Baby nicht schlechtreden und der Verbreitung im Wege stehen wollen. Außerdem ist es im globalen Kontext, dass eben ohne ECC RAM die Daten sowieso immer gefährdet sind, ja auch egal ob sie nun mehr oder weniger in Gefahr geraten.
Wenn Du Dir Gedanken um BTRFS machst, denn erwartest Du also vermutlich mehr Schutz vor Silent Data Corruption als der gewöhnlich Heimanwender und Fertig-NAS Kunde, der auch mit dem von Consumer HW üblichen Sicherheitsniveau zufrieden ist. RAM passieren, aber sie kommen nicht dauernd und überall vor, sonst würde auch kein Mensch solche NAS kaufen. Consumer HW soll billig sein und meistens bei den meisten fehlerfrei laufen, solange das gegen ist, wird kein Cent für mehr Schutz vor Fehlern ausgegeben. Das tun die NAS, aber mehr Sicherheit durch BTRFS zu versprechen ohne ECC RAM einzusetzen, was gerade beim DS415+ mit seinem Atom C2538 nur einen 9. RAM Chip und ein paar Verbindungen auf dem Mainboard kosten würde, ist mit Verlaub schwerste Kundenverarschung von den NAS Herstellern.
Wenn Du wirklich Sicherheit vor Silent-Data-Corruption willst, dann nimm einen echten Server mit ECC-RAM, für solche HW wurden auch die Filesysteme wie ZFS und BTRFS entwickelt, weshalb sie auch ihre Datenstrukturen im RAM nicht schützen, nur leider hat man darauf verzichtet diese wirklich als technische Voraussetzung zu erklären, wohl um die Verbreitung zu beschleunigen. Diese Filesystem sind für Pentabytestorages entwickelt, die haben auch nicht einmal ein Recoverytool, weil man bei Produktionssystemen eben kein Recovery probiert, wenn mal der schlimmste Fall eintritt. Da zählt für den Techniker nur dem Chef sagen zu können, wann das System wieder am laufen ist und bei einem Recoveryversuch könnte er das nicht, er wüsste ja nicht ob es gut ausgeht. Also werden da in jedem Fall die Backups zurückgespielt, da weiß man recht genau wie lange es dauert, der Chef schluckt dann wenn er hört wie lange es dauert, aber wenn es nach der angegebenen Zeit oder besser kurz vorher wieder läuft, ist alles gut. Klappt es nicht, ist K*cke am dampfen, also riskiert niemand Zeit mit ungewissen Dingen zu verschwenden, daher gibt es keine Recoverytools, die braucht die Zielgruppe nicht und die Heimanwender mit ihren winzigen 10 oder 20TB Storages brauchen solche Filesysteme nicht.
Vergiss nicht das Scrubbing, welche ein RAID gewöhnlich macht. OMV macht es per Default einmal im Monat, da kommen bei 4TB Platten dann schon 48TB zusammen und viele empfehlen es wöchentlich zu machen, damit sind es dann 200TB und damit mehr als der Workload selbst von Enterprise Cloud HDDs. Srubbing macht man in einem RAID um zu verhindern, dass es so viel unerkannte schwebende Sektoren und damit Lesefehler gibt, dass es doch passiert das es auf zwei Platten im gleichen Bereich einen gibt, womit das Rekonstruieren der Daten eines RAIDs dann fehlschlagen würde."
n4Computer sagt Nein
Bei Einwänden, Beiträge oder hilfreichen Links habt einfach melden/posten.
Was sind denn die Probleme um die man sich kümmern muss?
Worum geht es bei dem Thema im Kern?
Warum eigentlich ECC RAM?
Wann brauche ich ein Backup trotz Raid?
Worauf muss ich bei ECC Speicher achten?
Gibt es unterschiedliche Arten von ECC?
Kann mir nicht jemand das lesen abnehmen?
Warum eigentlich ECC RAM?n4
Zitat von Holt
"Desktopplatten in ein NAS zu bauen würde ich niemandem empfehlen, schon gar nicht bei einem 4 Bay NAS. Hinterher taugen natürlich dann die Platten nichts, wenn die das nicht lange mitmachen
Aufwand bei Einrichtung und Wartung hast Du bei einem Fertig-NAS auch, der ist bei einem System wie OMV, welches eine fertige Distribution von einem Debian Linux für NAS Anwendung ist, nicht wirklich höher.
Erstens hat auch das DS716+ die Prüfsummen nur zur Erkennung und nicht auch Korrektur bei Fehlern aktiviert und zweitens ist das auch gut so und verantwortungsvoll. Das DS716+ hat nämlich genauso wenig ECC RAM wie das DS415+, wobei es beim DS415+ wirklich unverständlich ist, da dessen Atom C2538 sogar ECC RAM unterstützen würde, man hat nur eben keines verbaut, weil die NAS Hersteller diese Feature nur den ganz teuren Kisten spendieren.
Filesysteme mit Fehlerkorrektur über Prüfsummen sind aber ohne ECC RAM nicht nur Schwachsinn, sondern sogar gefährlicher Blödsinn. Schwachsinn ist es, weil HDDs praktisch nie falsche Daten rückliefern, die liefern dann einen Lesefehler und keine korrupten Daten, wenn die Daten eines Sektors nicht zur ECC dahinter passen. Das dies unerkannt bleibt, also die Daten falsch sind und trotzdem zur ECC passen, ist so gut wie ausschlossen. Die Übertragung über SATA wird ebenfalls abgesichert, da gibt es eine CRC32 hinter jedem FIS, also jedem Übertragungspaket welches bis zu 8192 Bytes Nutzdaten haben kann und das reicht um nur etwas weniger als einen von 10^40 Fehler nicht zu erkennen, das mal 8k ist ein Datenvolumen größer als das Internet und da man Ultra-DMA Fehler wegen der Verzögerung bei der Übertragung und in den S.M.A.R.T. Werten sowieso erkennt, sollten die sowieso behoben werden, also praktisch dürfte wohl noch nie ein Fehler bei der SATA Übertragung unbemerkt geblieben sein.
Damit bleiben nur Fehler auf den internen Datenpfaden oder Fehler aufgrund von FW Bug der Platte oder des Host Controllers die so eine Prüfsumme erkennen kann und die man sonst nicht durch Lesefehler von der Platte erkannt hätte. Solche Lesefehler sind bei einem funktionierenden echten RAID (also kein RAID 0) dann aber auch kein Problem, da über die Paritydaten die Daten rekonstruiert und wieder auf die Platte mit dem Fehler geschrieben werden. Nur dann liest ein normaler Linux SW RAID überhaupt mal die Paritydaten aus. Ein FS mit Prüfsummen liest die immer (geht auf die Performance) und meldet jeden Fehler, nur wenn der Fehler im RAM passiert ist weil eben kein ECC RAM verwendet wird, denn gibt es mindestens mal einen Fehlalarm das eine Datei korrupt sein.
Wird nun aber auch die Fehlerkorrektur verwendet und die Paritydaten bzw. Prüfsumme ist gerade in dem RAM Bereich wo ein Fehler vorliegt, denn wird es schnell kritisch, diese Filesysteme trauen ihren Prüfsummen nämlich mehr als den gelesenen Daten und korrigieren den vermeidlichen Fehler und schreiben die nun kaputtkorrigierten Daten zurück. Bei einem hard-error der RAMs, also einem wiederholt an bestimmten RAM Adressen bei stimmten Bitmustern auftretenden Fehler, frisst sich der Fehler dann wie ein Krebs durch die Daten und wenn die Metadaten betroffen sind, ist der Pool kaputt und mit Pech hat man die korrupten Daten schon auf dem Backup. Berichte von Leute denen sowas mit ihren ZFS Pools auf Consumer-HW ohne ECC passiert ist, finden sich zu genüge im Netz.
Dagegen ist das was bei einem Linux md SW-RAID bei RAM Fehlern passiert geradezu harmlos, denn die RAID sind ja nicht auf zugleich Filesysteme, wie eben ZFS und BTRFS, die beides sind, RAID und Filesystem. Auf einem md-RAID kann man jedes Filesystem verwenden, die Daten des Filesystems werden vom darunter liegen Layer des RAIDs daher auch nie geändert, außer eben bei der oben beschrieben Rekonstruktion, aber die ändert ja auch keine Daten. Gibt es hier einen RAM Fehler, werden die Daten oder die Parity falsch geschrieben, sind die Daten betroffen war es das, aber bei ZFS oder BTRFS ist das nicht anders, wenn die Daten von der Netzwerkkarte kommen und in einem RAM Bereich mit einem Fehler landen, werden die vom Filesystem auch schon verändert gelesen, die Prüfsumme wird über die korrumpierten Daten gebildet und der Fehler ist permanent, man fühlt sich nur in der falschen Sicherheit sie wären korrekt.
Wird beim md SW-RAID die Parity falsch geschrieben, werden die Daten nur in dem Fall korrupt, wenn dann auch in dem betroffenen Bereich ein Lesefehler passiert und Daten rekonstruiert werden müssen, was ja nun auch nicht so oft auftritt. Die RAM Fehler haben da also weniger gravierende Auswirkungen, auch wenn sie ebenfalls das Filesystem korrumpieren können, wenn Metadaten betroffen sind und in jedem Fall können die Nutzerdaten unbemerkt korrupt sein, wenn diese Veränderung eben vor dem Schreiben im RAM passiert ist, nur wiegt man sich eben nicht in einer falschen Sicherheit.
Man sollte es mit Matt Ahren halten, einem der Mitentwickler von ZFS und der rat dazu zu aller erst einmal ECC RAM und natürlich ein passendes System welches dieses auch unterstützt zu verwenden, wenn man seine Daten liebt:
Besonders gerne missverstanden wird übrigens dieser erste Teil seines Posts aus dem das Zitat stammt: Die eigentliche Aussage des Satzes habe ich mal hervorgehoben, aber weil eben Filesysteme wie NTFS oder ext gerne auf Desktops ohne ECC genutzt werden, versuchen viele darauf abzuleiten man könnte dies auch genauso gut mit ZFS machen, weil ja nichts bei ZFS speziell nach ECC RAM verlangt was es bei anderen Filesystemen nicht auch tun würde. Richtig ist aber und das wird ja auch im Satz "if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data" klar, dass kein System ohne ECC RAM sicher für die Daten ist und man beim ECC RAM eben anfängt, dann erst lohnt es überhaupt erst sich um Prüfsummen Gedanken zu machen aber eben nicht umgekehrt. Ohne ECC RAM ist es dann auch egal ob man ein Filesystem mit Prüfsummen hat oder nicht.
Das der erste Teil "There's nothing special about ZFS that requires/encourages the use of ECC RAM" so nicht ganz stimmt, habe ich ja schon erklärt, aber er wird sein Baby nicht schlechtreden und der Verbreitung im Wege stehen wollen. Außerdem ist es im globalen Kontext, dass eben ohne ECC RAM die Daten sowieso immer gefährdet sind, ja auch egal ob sie nun mehr oder weniger in Gefahr geraten.
Wenn Du Dir Gedanken um BTRFS machst, denn erwartest Du also vermutlich mehr Schutz vor Silent Data Corruption als der gewöhnlich Heimanwender und Fertig-NAS Kunde, der auch mit dem von Consumer HW üblichen Sicherheitsniveau zufrieden ist. RAM passieren, aber sie kommen nicht dauernd und überall vor, sonst würde auch kein Mensch solche NAS kaufen. Consumer HW soll billig sein und meistens bei den meisten fehlerfrei laufen, solange das gegen ist, wird kein Cent für mehr Schutz vor Fehlern ausgegeben. Das tun die NAS, aber mehr Sicherheit durch BTRFS zu versprechen ohne ECC RAM einzusetzen, was gerade beim DS415+ mit seinem Atom C2538 nur einen 9. RAM Chip und ein paar Verbindungen auf dem Mainboard kosten würde, ist mit Verlaub schwerste Kundenverarschung von den NAS Herstellern.
Wenn Du wirklich Sicherheit vor Silent-Data-Corruption willst, dann nimm einen echten Server mit ECC-RAM, für solche HW wurden auch die Filesysteme wie ZFS und BTRFS entwickelt, weshalb sie auch ihre Datenstrukturen im RAM nicht schützen, nur leider hat man darauf verzichtet diese wirklich als technische Voraussetzung zu erklären, wohl um die Verbreitung zu beschleunigen. Diese Filesystem sind für Pentabytestorages entwickelt, die haben auch nicht einmal ein Recoverytool, weil man bei Produktionssystemen eben kein Recovery probiert, wenn mal der schlimmste Fall eintritt. Da zählt für den Techniker nur dem Chef sagen zu können, wann das System wieder am laufen ist und bei einem Recoveryversuch könnte er das nicht, er wüsste ja nicht ob es gut ausgeht. Also werden da in jedem Fall die Backups zurückgespielt, da weiß man recht genau wie lange es dauert, der Chef schluckt dann wenn er hört wie lange es dauert, aber wenn es nach der angegebenen Zeit oder besser kurz vorher wieder läuft, ist alles gut. Klappt es nicht, ist K*cke am dampfen, also riskiert niemand Zeit mit ungewissen Dingen zu verschwenden, daher gibt es keine Recoverytools, die braucht die Zielgruppe nicht und die Heimanwender mit ihren winzigen 10 oder 20TB Storages brauchen solche Filesysteme nicht.
Vergiss nicht das Scrubbing, welche ein RAID gewöhnlich macht. OMV macht es per Default einmal im Monat, da kommen bei 4TB Platten dann schon 48TB zusammen und viele empfehlen es wöchentlich zu machen, damit sind es dann 200TB und damit mehr als der Workload selbst von Enterprise Cloud HDDs. Srubbing macht man in einem RAID um zu verhindern, dass es so viel unerkannte schwebende Sektoren und damit Lesefehler gibt, dass es doch passiert das es auf zwei Platten im gleichen Bereich einen gibt, womit das Rekonstruieren der Daten eines RAIDs dann fehlschlagen würde."
n4Computer sagt Nein
Bei Einwänden, Beiträge oder hilfreichen Links habt einfach melden/posten.
Zuletzt bearbeitet von einem Moderator:
ergreifen müsste, bekommt man vielleicht ein Gefühl dafür, warum Unternehmen für ihre WIRKLICH WICHTIGEN DATEN einen Monsteraufwand fahren und ein Heidengeld ausgeben. 
- 
