Selbstbau NAS Aufrüstung

[conf_t]

Ich kann zu ECC nur sagen, meine Daten auf dem NAS sind teilweise bereits 23 Jahre alt. Gerade die alten, noch aus der Prä-ECC Ära bei mir, haben zahlreiche Bit-Flips. Gerade bei MP3/acc gut zu hören, wäre ich nicht so faul, könnte ich neue MP3 erstellen, da ich auch die kopierschutzfreie CD besitze, falls sie noch „gut“ ist.

Seit Umstellung auf ECC habe ich keine neuen Bitflips festgestellt. Ob das an ECC liegt oder an was anderem kann ich nicht genau beurteilen, Aber zumindest eine Korrelation ist da.

 

[scooter010]

Die 80€ sind für mich nicht wirklich relevant, sondern eher die Frage, ob die zwei Extrakerne den Stromverbauch im Ganzen gesehen erhöhen.

Weil? 80 €, dafür kann man schon eine Zeit lang den kleineren Prozi laufen lassen... Wenn Geld irrelevant ist, dann ist es auch der Stromverbrauch, es sei denn, es gibt eine USV/Kühlung, die auf Kante läuft.

 

[conf_t]

Im Idle machen die Anzahl der Kerne weniger was aus, er die Anzahl der Dies der CPU. Also ob 2 4 6 oder 8 Kerne ist im Idle wurscht. Ob 1x 8 Kerne oder 2x 6 oder 2x 8 nicht mehr ganz, weil die bei AMD 2 CCX und 1 IO-Die haben und nicht 1 CCx und 1 IO-Die

https://www.computerbase.de/2021-08...istungsaufnahme_und_temperatur_in_anwendungen

 

[Invader Zim]

Das bezieht sich auf das „falsche“ builtin DDr5-ECC (on-Die) was nicht vergleichbar mit dem „richtigen“ ECC (on-DIMM und on Mem-Controller) was es nebenbei auch für DDR5 (-Xeons) gibt.

Ok, danke für die Erklärung. Ein neuer Xeon mit DDR5-Unterstützung ist aber definitiv zu viel des Guten (sowohl Leistung als auch preislich (gerade zusammen mit dem passenden Board)).

@derchris ECC ist für ZFS wohl wirklich ein Must-Have Feature. Habe nachdem ich mein System neu Aufspielen musste mich zu dem Thema ein wenig eingelesen, und es wird von allen Seiten dringend empfohlen. Wenn das ZFS einen Fehler feststellt ist das Kind ja bereits in den Brunnen gefallen.

Und ja Proxmox kenne ich, ich sehe aber keinen Sinn darin Proxmox zu installieren, um damit zwei Systeme laufen zu lassen.
Das Problem mit der Raspberrymatic lässt sich für Openmediavault am kürzesten Beschreiben mit:

Raspberrymatic läuft als Docker, benötigt aber gewisse Funkmoduldateien (einfachste Umschreibung) im System, damit es funktioniert. Diese Dateien werden bei einem Systemupdate auch geupdated.
Ist soweit auch nicht schlimm, aber der Dockercontainer, welcher ja auch Updates bekommt (und teilweise auch benötigt) möchte dann immer eine gewisse Version haben.
Ein Schiefstand zwischen den Beiden ist nie gut - bei Fehlern aber von Nöten (das sind immer die schönsten Fälle).
OMV kriegt sich auch ab und an in die Haare mit den Updates, so dass man alle Header neu lesen/installieren muss. Kurz gesagt - Pain in the ass.

Ich weiß, dass die Supervised Installation in Truenas Scale auch nur eine virtualisierte Umgebung ist, aber mit ein wenig Aufwand im vorhinein, spare ich mir die Zeit nachher. Home Assistant selber erstellt dann die Raspberrymatic (als Docker), aber kümmert sich um alle Updates der virtuellen CCU, sowie des Unterbaus.

 

[Banned]

Ich kann zu ECC nur sagen, meine Daten auf dem NAS sind teilweise bereits 23 Jahre alt. Gerade die alten, noch aus der Prä-ECC Ära bei mir, haben zahlreiche Bit-Flips. Gerade bei MP3/acc gut zu hören,

Hatte ich auch mal bei einigen MP3s, die länger einfach auf ner Platte rumgelesen haben. Man konnte es allerdings bei keiner einzigen hören (zumindest für meine Begriffe). Hätte es das Programm nicht erkannt, wäre es mir nie aufgefallen. Wenn bei 320Kbit/s etc. ein Bit falsch ist, fällt das halt nicht zwangsweise auf. Wenn es mehrere sind, sieht die Sache sicherlich schon anders aus.

Konsequenterweise müsste man ja eigentlich auch sein Hauptsystem, mit dem man rippt/downloaded etc., auf ECC umstellen.
ECC im NAS erfüllt bei mir deshalb hauptsächlich den Zweck, dass die Prüfsummen korrekt berechnet werden bzw. im Falle eines Rebuilds dieser fehlerfrei abläuft (die Daten korrekt berechnet werden).

Seit Umstellung auf ECC habe ich keine neuen Bitflips festgestellt. Ob das an ECC liegt oder an was anderem kann ich nicht genau beurteilen,

Eher unwahrscheinlich. ECC-Fehler treten m.W. sehr selten auf. Wenn man allerdings Daten länger auf ner HDD verstaut, kann es zu Silent Data Corruption kommen. Es lag also mMn eher daran, dass du die Daten nicht häufig genug überprüft hast.


PS: Es fängt ja schon damit an, dass dein Router sicherlich keinen ECC-Arbeitsspeicher verwendet. Dateien, die nicht in einem Archiv gepackt sind, eine Signatur haben, oder für die eine Prüfsumme zum Abgleich geliefert wird (welchen man dann auch machen müsste), kann man somit im Grunde auch nicht trauen.

 

[Rickmer]

Dateien, die nicht in einem Archiv gepackt sind, eine Signatur haben, oder für die eine Prüfsumme zum Abgleich geliefert wird (welchen man dann auch machen müsste), kann man somit im Grunde auch nicht trauen.

Ein Glück, dass Dateitransfer per TCP nicht UDP stattfindet...

Bildliche Erklärung:

 

[conf_t]

Eher unwahrscheinlich. ECC-Fehler treten m.W. sehr selten auf. Wenn man allerdings Daten länger auf ner HDD verstaut, kann es zu Silent Data Corruption kommen.

Kann alles sein, nur "verstaut" habe ich die Daten nie, anfangs waren die auf der OS Platte, also sie lag nicht offline in der Ecke, später dann auf einem Quasi-NAS RAID5 seit 2006 und mal Linux und Mal Windows als OS, . Spätestens alle zwei Jahre sind die Dateien auf eine neue Platte umgezogen, und für die 2000er Jaher üblich, waren die RIPs von damals nur in 128 kbps und da habe ich je nach Lied auch deutlich mehr als nur 1 Flip.

Wo genau die Flips passiert sind, kann ich hinterher natürlich nicht sagen, aber das typische Szenario, dass die HDD 1 oder 2 Jahre offline in der Ecke lag war es nicht. Seit 2016 mit ECC unterwegs und keine neuen Bitflips bemerkt.

Ergänzung (17. Dezember 2023)

Ein Glück, dass Dateitransfer per TCP nicht UDP stattfindet...

Nicht nur das, man hat natürlich auch noch den Ethernet-Frame CRC als Point-2-Point Korrektur, die in Kombination mit TCP ein Bitflip auf der Leitung nahezu unmöglich macht, erst im jeweiligen System könnte es hier und da kritisch werden.

 

[Flossen_Gaming]

Mit was lässt sich ein Bit-Flip denn am besten erkennen?

 

[conf_t]

Es fängt ja schon damit an, dass dein Router sicherlich keinen ECC-Arbeitsspeicher

Ein Router der als Router vom Hersteller gebaut wurde, routet in Hardware, das Datenpaket sieht zu keinem Zeitpunkt den RAM, dass landet nur im Interfacebuffer, der eh nur wenige kB groß ist. Den braucht der Router für die Konfig, das OS, den Webserver, die CLI, die Nutzerverwaltung und Zusatzfunktionen, wie DNS, DHCP,… und das erzeugen/berechnen der Routingtabllen. Bei den Selbstbau - ich vergewaltige - meinem - PC - zum- Router-Projekten mag das anders ausehen.

Ergänzung (17. Dezember 2023)

Mit was lässt sich ein Bit-Flip denn am besten erkennen?

Prüfsummen von der Originaldatei und der Vergleichsdatei.

 

[Banned]

Ein Glück, dass Dateitransfer per TCP nicht UDP stattfindet...

Danke für die netten Bildchen, aber darum ging es mir nicht. Mir ging es darum, ob/welche Daten im Router auf dem RAM liegen. Denn natürlich kann man auch korrumpierte Daten fehlerfrei über ein sicheres Protokoll transferieren. Wenn das Bit im flüchtigen Speicher des Routers kippt, hat der Transfer bzw. das dazu verwendete Protokoll damit nichts zu schaffen - der Transfer war ja erfolgreich.

Ein Router der als Router vom Hersteller gebaut wurde, routet in Hardware, das Datenpaket sieht zu keinem Zeitpunkt den RAM, dass landet nur im Interfacebuffer, der eh nur wenige kB groß ist.

Okay, und bei wenigen kB im Interfacebuffer können keine Bitfehler auftreten? Aber ich nehme mal an, der ist dann bei dieser geringen Größe entsprechend abgesichert.

Dann habe ich was gelernt. Danke.

Ergänzung (17. Dezember 2023)

Kann alles sein, nur "verstaut" habe ich die Daten nie, anfangs waren die auf der OS Platte, also sie lag nicht offline in der Ecke, später dann auf einem Quasi-NAS RAID5 seit 2006 und mal Linux und Mal Windows als OS, . Spätestens alle zwei Jahre sind die Dateien auf eine neue Platte umgezogen, und für die 2000er Jaher üblich, waren die RIPs von damals nur in 128 kbps und da habe ich je nach Lied auch deutlich mehr als nur 1 Flip.

Ob die Platte in der Ecke liegt oder ob die Daten irgendwo in nem System liegen und extrem selten verwendet werden, macht auch keinen Unterschied. Zwei Jahre sind kein langes Intervall, aber auch hier kann man leider Pech haben.

Bei nem RAID wäre es halt gut, wenn man regalmäßig einen Scrub durchführen würde. Aber vielleicht war auch irgendwie was anders im Argen bzw. du hattest großes Pech. Der ECC-RAM bringt ja eigentlich nur was, wenn die Daten transferiert werden und bei den Berechnungen beim Anlegen, beim Scrub und beim Rebuild.

 

[Rickmer]

Danke für die netten Bildchen, aber darum ging es mir nicht. Mir ging es darum, ob/welche Daten im Router auf dem RAM liegen. Denn natürlich kann man auch korrumpierte Daten fehlerfrei über ein sicheres Protokoll transferieren. Wenn das Bit im flüchtigen Speicher des Routers kippt, hat der Transfer bzw. das dazu verwendete Protokoll damit nichts zu schaffen.

Naja, wie conf_t erwähnt hat: Dann passt das nicht mehr zur frame check sequence (FCS) im Ethernet-Frame und wird (TCP sei dank, siehe mein nettes Bildchen) neu geschickt.

Daher sind Bitflips irgendwo auf dem Weg alle irrelevant und sorgen nur für höheren Overhead.

 

[Banned]

Naja, wie conf_t erwähnt hat: Dann passt das nicht mehr zur frame check sequence (FCS) im Ethernet-Frame und wird (TCP sei dank, siehe mein nettes Bildchen) neu geschickt.

Das betrifft doch aber auch wieder nur den Transfer.

Die Daten können doch fehlerfrei aus dem Internet zum Router kommen, dort im flüchtigen Speicher durch einen Bitflip korrumpiert werden, und dann gemäß TCP korrekt zum Endgerät übertragen werden. Bei der Übertragung gab es dabei zu keinen Zeitpunkt ein Problem. Trotzdem sind die Daten korrumpiert.

Wenn es natürlich so ist, wie @conf_t sagt, und die Daten nur in den Interface Buffer gelangen - wobei ich mal annehme, dass man dann so schlau gewesen ist, diesen bei der geringen Größe mit entsprechenden Prüf-/Korrektur-Algorithmen auszustatten, dann ist natürlich alles gut. Am Transfer lag es dann aber trotzdem nicht.

 

[Rickmer]

Die Daten können doch fehlerfrei aus dem Internet zum Router kommen, dort im flüchtigen Speicher durch einen Bitflip korrumpiert werden, und dann gemäß TCP korrekt zum Endgerät übertragen werden. Bei der Übertragung gab es dabei zu keinen Zeitpunkt ein Problem. Trotzdem sind die Daten korrumpiert.

Sofern du nicht einen http Proxy auf deinem Router betreibst, der den Traffic auswertet und neu verpackt, wird das nicht passieren... das ECC vom Ethernet-Frame geht Server zu Client.