Bestehenden Server eweitern

Da würde ich es mit Matt Ahren, einem Mitentwickler des ZFS-Dateisystems, halt, der schreibt:
Man beachte die Reihenfolge, zuerst empfiehlt er ECC RAM und dann erst oben drauf ein Filesystem mit Prüfsummen wie ZFS zu verwenden, wenn man seine Daten liebt und vor Korruption schützen möchte!

Meines Wissens kann man bei ZFS immer noch keine weiteren Platten in den Pool einfügen, sondern sie nur anfügen. Die werden also ähnlich wie JBOD (BIG) dann rangehängt, aber genießen eben nicht den gleichen Schutz wie die Platten im Pool. Man kann aber kleinere Platte durch größere ersetzen und so den Pool erweitern.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
In der Diskusioin ging es darum ob es bei ZFS eine erhöhte Notwendigkeit für ECC gibt, nicht darum dass ECC sinnvoll ist

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. 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. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

Ansonsten funktioniert ZFS etwas anders als ein einfaches Raid-5/6 bei dem mehrere Platten zu einem Raid zusammengefasst werden. Da ist es dann teilweise möglich aus einem Raid mit 5 Platten eines mit 6 Platten zu machen. Das ist bei ZFS nicht vorgesehen. Konzeptionelles Ziel sind auch nicht Raid aus wenigen Platten sondern Petabyte Storage mit Dutzenden von Platten.

ZFS nutzt dafür vdevs. Das ist sowas wie ein Raid 1/5/6 aber ohne dessen write hole Problem. Erweitert wird das indem man ein weiteres Raid/vdev anfügt. ZFS striped dann über diese vdevs/Raids. Dadurch steigt neben der Kapazität auch die Performance.
 
Zuletzt bearbeitet:
Es gibt nicht spezielles was bei ZFS ECC verlangt bedeutet nur, dass man erstens ZFS auch auch Systemen ohne ECC RAM zum Laufen bekommt und außerdem jedes Filesystem durch RAM Fehler die die Metadaten korrumpieren kaputt gehen kann. Das Problem bei ZFS und anderen Filesystemen mit automatischer Fehlerkorrektur ist aber, dass diese die Daten beim RAM Fehler kaputt korrigieren, was bei anderen Filesystemen so nicht passiert. Solche Filesysteme sind für Server-HW ausgelegt, ECC RAM ist da selbstverständlich und daher attributieren sie alle Fehler immer auf Fehler der Platten und korrigieren sie dann entsprechend. Es macht ja auch keinen Sinn sich Gedanken um Datenfehler auf den Platten Gedanken zu machen, wenn man das viel größere Einfalltor RAM Fehler nicht schließt.

Aber bitte, wer ZFS ohne ECC RAM nutzen möchte, der sollte dann eben im Zweifel hoffen, dass wenigstens die Daten auf dem Backup noch heil sind, dann selbst das weiß man nicht. Der Mechanismus ist nämlich so, dass wenn da ein Wert eingelesen und im RAM wegen einer Fehlers verfälscht wurde, diese Fehler zu einer "Korrektur" der Parity Daten führt, was dann eben eine Kaputtkorrektur ist und daher fressen sich RAM Fehler langsam durch den Pool ohne das der User dies merkt, es wurden eben Fehler gefunden und korrigiert was ja toll klingt, man gut man hat ZFS genommen :hail:

Erst wenn mal wichtige Metadaten betroffen sind, knallt es richtig. Bei einem md-SW RAID mit ext4 daruf wäre ein RAM Fehler nur dazu führen, dass die Daten eben falsch weitergereicht würden, die korrekten Daten auf den Platten aber nicht verändert werden, da md SW RAIDs die Parity gar nicht mitlesen (erhöht auch die Performance), sondern erst auf diese zugreifen, wenn eine Platten beim Lesen einen Lesefehler meldet und die Parity also auch wirklich benötigt wird. Auch da knallt es natürlich, wenn wichtige Metadaten des Filesystems die gerade im RAM liegen durch RAM Fehler verändert werden, aber die sind bei ZFS auch noch ungleich größer.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh