Zum Thema ZFS ohne ECC steht ja bereits was im verlinkten Artikel. Ansonsten das was du beschreibst ist eine der Möglichkeiten.
Zu schreibende Daten werden auf dem System erzeugt (oder kommen von außen irgendwie dahin), wandern immer in den RAM und werden ans StorageSubSystem (HBAs/Controller und dann an die jeweiligen Laufwerke) weiter gegeben. Das ist aber keine Besonderheit von ZFS sondern so ziemlich überall wenn man von klassischem Storage spricht. Bei HPC Lösungen mit Infiniband und RDMA oder NVMeoF ist das etwas anders aber damit werden die allerwenigsten hier jemals auch nur ansatzweise in Betracht kommen.
Eine 2009 vorgestellte Studie untersuchte die Fehlerraten in allen damals weltweit vorhandenen Datacenter von Google und kam (stark verkürzt) zum Ergebnis, dass ~8% aller DIMMs pro Jahr Fehler aufwiesen (
Quelle).
Im absoluten Worst Case kann das dann bei den eigenen Fotos und Erinnerungen so aussehen:
https://arstechnica.com/information...nd-atomic-cows-inside-next-gen-filesystems/3/ und ans Ende scrollen.
Hier im letzten Absatz vom Abschnitt Research ist auch ein Beispiel mit Excel. Aber wie gesagt: Worst Case Szenarien.
Wenn du beispielsweise ausschließlich Dateiformate verwendest die eigene Checksummen mitbringen dann bräuchte die Welt weder ZFS noch BTRFS etc. Aber das kostet Speicherplatz und ist doof für die Kompression, ergo sind wir wieder bei ZFS etc.
Gleiches gilt natürlich wenn die Daten schon Fehler aufweisen bevor diese in die Obhut von ZFS gegeben werden. Ein prominentes Beispiel von vielen war Xerox vor fast 10 Jahren:
https://media.ccc.de/v/31c3_-_6558_...u_nicht_selbst_gefalscht_hast_-_david_kriesel
Alternativ kannst du natürlich auch selbst mittels sha256 von allen deinen Daten die Checksummen erstellen und abspeichern und regelmäßig vergleichen inklusive der Daten im Backup und wenn es irgendwo eine Abweichung geben sollte, kannst es ja versuchen manuell wiederherzustellen oder greifst aufs Backup zurück aber wozu das Leben verkomplizieren?^^
Ein fehlerkorrigierendes Dateisystem zu verwenden ist also angebracht wenn man seine Daten mag. Warum sollte man dann auf der anderen Seite seine Daten gefährden durch RAM, der keine Fehler bemerkt? Das muss ja nicht nur beim initialen erstellen/abladen der Dateien sein. Reicht ja auch wenn ich auf dem System eine Datei bearbeite und abspeichere. Dann sollen natürlich auch nur meine eigenen Änderungen gespeichert werden und nicht "Änderungen" durch ein zufälliges Bit-Flip.
Wenn man dann natürlich die Daten vom NAS auf den Laptop kopiert, da verändert und wieder speichert und am Laptop treten Bitfehler auf, kann ZFS im NAS natürlich nix dafür und würde dies auch nicht erkennen können, woher auch? Da müsste man dann schon im Laptop ECC verwenden und auch die Übertragungswege absichern wobei das heutzutage bei so ziemlich jeder Art der verschlüsselten Übertragung der Fall ist.
Der vermeintlich hohe RAM-Verbrauch von ZFS kommt von der Nutzung des RAMs als ARC, also Lese-Cache. Ansonsten wird der "nur" verwendet wenn der hoffentlich regelmäßig eingerichtete Scrub läuft, da werden die eigentlichen Nutzdaten sowie deren Checksums von ZFS komplett eingelesen und verglichen und sollte ein fehlerhafter Sektor auf einer der HDDs vorliegen dann kann dies korrigiert werden. Die Checksummen der Daten nicht verwechseln mit den Paritätsdaten in den VDEVs (mirrored, raidz1/2/3), die dienen v.a. zur Wiederherstellung bei Ausfall einer kompletten HDD.
Bit-Flips passieren ja nicht nur im Ram sondern auch auf HDDs. Wie wahrscheinlich diese sind erkennt man rein statistisch im Datenblatt an der URE oder UBER. Aber das ist ein ganz anderes Minenfeld und dank der Eigenschaften von ZFS nicht ganz so schlimm ggü. "klassischen" Dateisystemen und für den Fall der Fälle hat man ja natürlich immer aktuelle Backups oder akzeptiert dann den Datenverlust nach ein wenig mimimi. Aber ich schweife schon wieder ab und hoffe, ich konnte die Fragen bzw. Vor- & Nachteile ECC halbwegs gut erklären.
