[Kaufberatung] Nas mit Ecc Ram

In der Diskussion ob man ECC RAM haben sollte wird oft übersehen dass es dabei nicht nur um defekten RAM geht oder um RAM der sehr viele Fehler aufweist. Das merkt man auch ohne ECC sehr schnell durch BSOD oder Kernelpanics. Das Unangenehme dabei ist nur die Unsicherheit ob neben dem Absturz auch Daten verfälscht wurden. Bei ZFS hat man zwar Prüfsummen auf den Daten und Metadaten, man kann aber nicht sicher sein ob hier nicht korrekte Prüfsummen auf verfälschten Daten aufgebracht wurden. Eigentlich müsste man jetzt das Backup zurückspielen um ganz sicher zu sein und da kann es auch Probleme beim Zurückspielen geben.

Neben kaputtem RAM gibt es aber auch RAM Fehler bei ansonst fehlerfreien RAM die einfach mit einer sehr geringen statistischen Häufigkeit auftreten, umso häufiger je mehr RAM man hat, je wärmer es ist oder je kleiner die Chip Strukturen sind. Die sind eher noch gemeiner weil da merkt man meist nichts, allenfalls wenn ein Bild plötzlich einen schwarzen Streifen hat. Dann kann man sich aber auch nicht sicher sein ob ein RAM Fehler oder bitrot die Ursache war, ein anderes statistisches Problem bei dem Daten "rosten" obwohl die Platten fehlerfrei sind. Auf den Platten wird zwar auch blockweise ECC eingesetzt weil man bei aktuellen Datendichten fast nur noch schätzen kann ob die Daten gut sind oder nicht, das verringert aber auch nur die statistische Häufigkeit unentdeckter oder nicht korrigierbarer Fehler.

Je genauer man hinsieht desto mehr Gefahren erkennt man für die Sicherheit der Daten und oft ist Zufall/Statistik das Problem. Daher auch der Rat ECC + ZFS zu nehmen. Damit hat man nach dem Stand der Technik die geringste Wahrscheinlichkeit eines Datenverlustes oder unerkannten Datenveränderung. Ausschließen kann man damit Fehler auch nicht, nur die Eintrittswahrscheinlichkeit um Größenordnungen verringern.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
da würde mir das hier am besten gefallen weil es mini itx ist und es in ein jonsbo N2 Gehäuse passt. Oder habt ihr besser Gehäuse Vorschläge wo auch 4 hdd rein passen?Bei dem Preis ist ja kühler und CPU auch schon dabei oder sehe ich da was falsch?
 
Das ist ja das Mini ITX Board von dem in den letzten Beiträgen geschrieben wurde.

Aktuell habe ich das Board in einem SilverStone SST-DS380B, ist mir aber alles zu eng. Habe jetzt ein Jonsbo N3 bestellt.
 
Das Gigabyte Board kann ich für ein Selbstbau-Nas sehr empfehlen. 8x Sata auf Mini -ITX + IPMI und frisst eigentlich jeden günstigen DDR4 ECC Rdimm.
 
Ja, siehst du richtig. Der CPU Fan ist aber nicht gerade leise. Im neuen Gehäuse mach ich einen neuen Größeren drauf.
 
Und aufpassen bei der RAM-Wahl: das Ding kann REGISTERED. Oft gehen dann auch unregistered, aber mit RDIMMs kann man nen Euro sparen und außerdem mehr unterbringen. :)
 
Verstehe nicht warum nicht die meisten Qnap/Synology/Selbstbaulösungen von haus aus eingebaut haben.
Die nutzen ECC nicht, weil die passenden CPUs kein ECC unterstützen. Und die CPUs unterstützen kein ECC, weil dadurch das ganze System günstiger wird und es auch ohne ECC geht. Ich kann mich auch nicht entsinnen, jemals gehört oder gelesen zu haben, dass es wegen fehlendem ECC Probleme gegeben hätte. Die NAS-Hersteller können die Systeme aber viel besser testen und abstimmen, als man es beim Eigenbau kann.

Es gibt ja auch Milliarden anderer Systeme, die wunderbar ohne ECC laufen: Smartphones, Tablets, (die meisten) Notebooks, Router, Konsolen etc.

Der normale Endkunde schaut als erstes auf den Preis, kennt sich mit den Details nicht aus und in der Regel passiert nichts, was der Kunde merkt.
Dieses "was der Kunde merkt" impliziert für mich, dass du glaubst, das etwas schlimmes passiert, was unbemerkt bleibt.

Schlimmer wirds nur, wenn man kaputten RAM lange unbemerkt benutzt, dadurch die Daten in größerem Stile fehlerhaft werden und man davon kein Backup hat oder das Backup sogar schon die defekten Daten enthält.
Genau das kann nicht passieren. Dass der RAM defekt ist, aber das System weiter stabil läuft, klappt nicht. Jeder, der schonmal defekten RAM hatte, weiß, dass der nicht lange unentdeckt bleibt.

Rauchen schadet der Gesundheit?
Erwärmt sich die Erde?
Das sind völlig unsinnige Vergleiche. Die kenne ich sonst nur von Versicherungsvertretern.

RAM ist wie alles auf dieser Welt nicht fehlerfrei. Man kann mit einer Wahrscheinlichkeit abschätzen wie oft Fehler auftreten ohne dass RAM defekt ist.
In dem heise-Artikel aus 2009(!) geht es doch darum, dass solche "Soft Errors" viel seltener auftreten, als man früher dachte. Bist du auf dem Kenntnisstand von vor 2009?

Die Wahrscheinlichkeit mag niedrig sein aber proportional zum RAM und ausreichend Wartezeit passiert garantiert ein RAM Fehler der mit einer bestimmten Häufigkeit zu einem Absturz oder verfälschten Daten führt.
Die Frage ist doch, wie lange man warten müsste. Die Erkenntnisse zu solchen Fehlern stammen aus Rechenzentren. Wenn man deren RAM-Menge und die Intensität der Nutzung auf ein NAS herunterbricht, kommen astronomische Wartezeiten raus.

Ob man das als relevant ansieht kann jeder selber entscheiden, genau wie jeder Rauchen darf soviel er will. Wenn man Risiken vermeiden möchte die mit einer gewissen Wahrscheinlichkeit einen vermeidbaren Schaden zur Folge haben, sollte man weder Rauchen noch auf ECC RAM verzichten.
Wie hoch schätzt du denn diese "gewisse[] Wahrscheinlichkeit" ein? Nachdem man Jahre auf das gekippte Bit gewartet hat, muss ja auch ein wichtiges Bit betroffen sein. Der RAM eines NAS hat Dutzende bis Hunderte Milliarden Bits. Mir ist klar, dass es nicht einfach ist, sich solche Zahlen vorzustellen, aber das ist kein Grund in Panik zu verfallen.

Dass billige NASen kein ECC haben liegt nicht daran, dass die Hersteller glauben dass damit kein Vorteil verbunden wäre, sondern allein daran dass das Geld kostet und die meisten Kunden kein technisches Verständnis haben.
Was hat denn das technische Verständnis der Kunden mit dem Risiko zu tun? Wenn die Kunden keine Probleme haben, gibt es vielleicht kein Problem. Oder glaubst du auch, dass in Wirklichkeit Daten beschädigt werden, aber es die Kunden nicht merken? Das klang bei besterino schon so an.

Halten wir also fest, dass du nicht im entferntesten verstanden hast, worüber wir hier reden.
Ich glaube wir haben einfach sehr unterschiedliche Vorstellungen von Heimservern und NASen. Für dich scheinen es hochfrequentierte Systeme mit hoher Auslastung zu sein. Für mich sind es Kisten, die die meiste Zeit im idle vor sich hindümpeln.

Wir reden hier von Servern bzw. NAS Systemen. Deren Hauptaufgabe das Handling von Nutzerdaten ist.
D.h. dass 99% der Daten, die durch RAM und co. fließen, Nutzerdaten sind.
Das ist das, was ich oben mit "Programmdaten konvergiert in dem Usecase nach Nutzerdaten" geschrieben habe.
Diese Systeme haben 90% der Zeit nichts zu tun und warten auf den Nutzer. In der Zeit ist nur das OS mit seinen Diensten im RAM. Gelegentlich werden Nutzdaten abgerufen und gelegentlich (eher seltener) werden Nutzdaten empfangen, verarbeitet und gespeichert
In diesem Kontext (ggf. nochmal den Eingangspost lesen, da ist von NAS die Sprache) hier ist die Sache aber anders. Hier werden nahezu ausschließlich Nutzerdaten gehandelt. D.h. dass 99% der RAM Fehler statisch auf Nutzerdaten und nicht auf Programmdaten wirken. Dieser Anteil wird im Wesentlichen dadurch bestimmt, wie die Nutzdaten auf dem System gehandelt werden.
Wie werden denn die daten da "gehandelt"? Ich weiß nicht, was du dir da vorstellst.
Liegen die Dateien wie bei einem Windowsfileserver einfach so auf der Platte, ist das ein ganz anderes Problem als bei modernen Dateisystemen, wo man mit den Daten, auch wenn sie nur so rumliegen und vom Nutzer gerade nicht benötigt werden, ganz anders gearbeitet wird. Die werden quasi ständig bearbeitet. D.h. auch wenn die Daten "cold" sind, sind im Sinne des Systems aber hot. D.h. der RAM ist hier "ständig" mit den Nutzdaten beschäftigt.
Ich habe ehrlich gesagt keine Vorstellung davon, was du hier meinst. Welches OS und welche Anwendungen meinst du, die mit den Nutzdaten ständig autonom "arbeiten" und die Nutzdaten dann anscheinend nach der Bearbeitung in veränderter Form schreiben?
Daher ist die Aussage, dass fast ausschließlich Programmdaten und nahezu keine Nutzerdaten betroffen sind, schlicht falsch. Das solltest auch du erkennen.
Ich erkenne es beim besten Willen nicht. Aber ich lasse mich gerne überzeugen. Vielleicht entgeht mir ja etwas.

Und rationaler und unvoreingenommener Ratschläge wäre, wenn man bei den Fakten bleibt. Und der Fakt ist, dass ECC besser ist. D.h. man sollte zu ECC Systemen raten.
Das sind keine Fakten, weil sie auf deiner persönlichen Risikoeinschätzung beruhen. Wenn die technischen Vorteile von ECC keine praktischen Vorteile für den Nutzer bringen, aber Kosten erhöhen, oder andere Einschränkungen bewirken, ist ECC gerade nicht "besser" und man muss nicht zu ECC raten. Aber du bist voreingenommen. Für dich ist ECC immer gesetzt. Egal ob es etwas bringt und egal, ob man nur zwei komische Boards günstig bekommen kann.
Ich habe Beispiele für günstige, wenn nicht sogar sehr günstige, Systeme genannt. Ich weiß nicht, warum man z.B. bei dem MiniITX EPYC Gigabyte MB der Meinung sein sollte, dass man das wegen ECC nicht einfach nimmt. Es mag andere Entscheidungsgründe dagegen geben, z.B. PCIe Slot, dann gäbe es ggf. noch das AM4 MB. In jedem Fall aber sind das sehr günstige Möglichkeiten für ECC. Da sind N100 MBs teuer und die können dann natürlich kein ECC. Man kann also festhalten, dass in diesem speziellen Fall ein ECC-System sogar günstiger als nen nonECC System ist. Daher ist die pauschale Aussage, dass ECC die Kosten erhöht sogar komplett falsch.
Die Kosten sind nur ein Punkt, der gegen ECC spricht. Und zu den Kosten gehört auch der Stromverbrauch, den du irgendwie ausklammerst.
Es gibt, gerade im Moment, sehr günstige Alternativen für ECC.
Wie schon gesagt, gilt das "sehr günstig" nur, wenn man den Stromverbrauch ignoriert. Ich habe auch AM4-Systeme mit ECC da, aber die können beim Stromverbrauch leider nicht mit dem D3417 mithalten.
Das ist falsch. Ich planen, unter anderem, bei uns die VM, Server und Storageinfrastruktur. In allen Systemen ist das Problem "Verfügbarkeit" freilich immer eine wichtiger Punkt. Der Punkt der Datenintegrität der tatsächlichen Nutzdaten ist aber genauso wichtig, wenn nicht sogar wichtiger.
99% der Systeme sind redundant, sogar mehrfach redundante. Es wäre also sogar verkraftbar, wenn ein System mal abstützt. Die Applikation würde dennoch kurz husten, geht aber weiter. Besser wäre schon ohne.
Das sieht bei der Datenintegrität aber anders aus. Die Daten müssen schon passen, weil die Folgekosten von Abweichungen schon schlecht wären. Freilich nicht wie im Bankensektor, die einen ganz anderen Aufwand treiben müssen.
Beim Storage wird dieses Problem potenziert. Man will bei etlichen PBs kein Risiko eingehen.
Das Argument halte ich für einen Zirkelschluss. Du stützt deine Meinung auf Tatsachen, die du mitgestaltet hast, ergo auf deiner Meinung beruhen.
Die pauschale Aussage, dass man ECC in Unternehmen hauptsächlich wegen Verfügbarkeit macht ist also auch falsch. Gerade große Unternehmen, die viel mit wichtigen Daten (als nicht nur irgendwelche Exchangeserver) zu tun haben, legen da einen ganz anderen Fokus.
Mit geht es darum, dass Unternehmen schon wegen der Anforderungen an die Verfügbarkeit nicht auf ECC verzichten können. Deshalb ist es m.E. schwierig aus der Tatsache, dass Unternehmen Systeme mit ECC nutzen auf Privatnutzer zu schließen.
 
Könnte den ein Mod nicht mal ruhigstellen?

Wenn dem am Ende einer glaubt…
 
@besterino Ich sage genau das, was auch die c't-Autoren sagen. In ihrem Heimserver-Bauvorschlag 2024 war auch kein ECC vorgesehen, obwohl die sogar auf AM4 gesetzt haben. Warum bringt dich das so auf die Palme?

Manche hängen zwei USB-Platten an einen Raspberry Pi und das läuft über Jahre problemlos und du glaubst, dass wer weiß was passiert, wenn jemand kein ECC nimmt.
 
Würde mir jetztMj11-Ec1 kaufen und diesen 32GB Ram. Oder würde es mehr sinn machen 2x16GB?
Als powersupply dieses bequit Netzteil.
Gehäuse würde ich dann doch eher das Jonsbo n3 kaufen.

Passen diese Komponenten für das Gehäuse und meine Anwendungen?

Schafft die CPU und Ram die 4x4TB HDD in raidZ mit deduplizierung und kompression? Oder soll dan deduplizierung und kompression deaktiviert werden? Oder wäre es besser noch 2 4tb hdd zu kaufen und auf raidZ2 zu gehen?
 
Der RAM ist UDIMM, der ist teuer als RDIMM, welcher auch geht.
 
Der RAM ist UDIMM, der ist teuer als RDIMM, welcher auch geht.
macht dan das keinen Unterschied weil ECC nur bei RDIMM steht?
UDIMM, UDIMM ECC, RDIMM modules up to 128GB supported
Memory speed: Up to 2666 MHz

sonst der Rest würde zusammenpassen?
 
macht dan das keinen Unterschied weil ECC nur bei RDIMM steht?
UDIMM, UDIMM ECC, RDIMM modules up to 128GB supported
Memory speed: Up to 2666 MHz

sonst der Rest würde zusammenpassen?

UDIMM teuer und nur 128 GB, RDIMM günstiger und bis zu 512 GB.
 
Die Frage ist doch, wie lange man warten müsste. Die Erkenntnisse zu solchen Fehlern stammen aus Rechenzentren. Wenn man deren RAM-Menge und die Intensität der Nutzung auf ein NAS herunterbricht, kommen astronomische Wartezeiten raus.


Wie hoch schätzt du denn diese "gewisse[] Wahrscheinlichkeit" ein? Nachdem man Jahre auf das gekippte Bit gewartet hat, muss ja auch ein wichtiges Bit betroffen sein. Der RAM eines NAS hat Dutzende bis Hunderte Milliarden Bits. Mir ist klar, dass es nicht einfach ist, sich solche Zahlen vorzustellen, aber das ist kein Grund in Panik zu verfallen.
Nur soviel, du solltest dir nochmal dringend anschauen, wie Stochastik funktioniert.
Mal ein Beispiel:
Ein 6er im Lotto tritt statistisch alle 14mio Ziehungen auf.
Glaubst du, dass Leute, die im Lotto gewinnen, bereits ~10k Jahre Lotto (2x wöchentlich) spielen? Nur zur Einordnung, die Pyramiden sind 4,5k Jahre alt. Wann, glaubst du, haben die Menschen angefangen Lotto zu spielen?
Viel mehr ist es so, dass Leute 1x Lotto spielen und dann direkt einen 6er haben. Wie erklärst du dir das? Die hätten ja schon 10k Jahre vorher mit anfangen müssen und das dann durchhalten müssen.
Weiterhin ist die Frage, wie verhält sich das mit dem Einsatz und Gewinn, wenn man 10k Jahre 2x in der Woche Lotto spielt. Kann man ja mal zum Spaß durchrechnen. Also, wie funktioniert das mit dem Lotto?
Wenn man das rausbekommen hat, weiß man auch, wie das mit dem ECC RAM funktioniert.
Also Lotto spielen um was über ECC zu lernen.


Zu allem anderen fehlt mir echt die Muße weiter drauf einzugehen.


Ein Stichwort zum Wissensaufbau:
Was mit Daten passiert, wenn sie gerade nicht genutzt werden? Schonmal was von scrubbing gehört?

Ansonsten sei nochmal abschließend gesagt, dass hier keiner gesagt hat, dass man Systeme nur mit ECC nehmen darf.
Der Tenor ist, nicht nur von mir, dass man das im Gesamten abwägen muss. (und zum Gesamten gehört unter anderem auch die Leistungsaufnahme)
Du aber hast den ultimativen Anspruch, dass ECC völlig unnötig ist.
Kann man sich mal fragen, wer da reflektierter an die Sache rangeht.

Und bei mir ist ECC gar nicht gesetzt. Nicht umsonst habe ich 8 Serversysteme ohne ECC hier. Na, wie gesetzt ist ECC bei mir?
Gar nicht so sehr? Wie kommt das? Nennt sich bedarfsgerechte Entscheidung. Klingt komisch, ist aber so.
 
Zuletzt bearbeitet:
Nur soviel, du solltest dir nochmal dringend anschauen, wie Stochastik funktioniert.
Mal ein Beispiel:
Ein 6er im Lotto tritt statistisch alle 14mio Ziehungen auf.
Ich stimme dir ja technisch zum ECC zu, aber das stimmt nicht, was du da schreibst. Das ist der Trugschluss des Spielers. Tatsächlich müsste man für für bereits lediglich eine 95%ige Wahrscheinlichkeit, dass man sechs richtige Zahlen im Lotto hat, mehr als 24 Millionen mal spielen. Aus deinen 10.000 Jahren bei zwei Ziehungen pro Woche werden da etwa 234.619 Jahre draus ;) Dabei wiederum stehen die Chancen gleichverteilt, dass es bei der ersten Ziehung wie bei der letzten passiert, was deine Aussage zu ECC vermutlich sein sollte.
 
@underclocker2k4 Ich bin in Schule und Uni ganz gut mit der Stochastik klargekommen, deshalb glaube ich, dass ich zumindest die Grundzüge verstanden habe. Ich weiß aber nicht, ob die Soft Errors bei RAM wirklich zufällig sind und mit der Lotto-Ziehung vergleichbar wären. Den Rest hat MrWahoo schon geklärt.

Das Thema ZFS+Scrubbing+Non-ECC-RAM aka "Scrub of Death" hat schon einen Bart. Das sollten wir vielleicht endlich hinter uns lassen. Hier nochmal zum Nachlesen: https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

Wenn wir uns einig sind, das man im Gesamten abwägen muss, ist doch alles gut.
 
@underclocker2k4

Das Thema ZFS+Scrubbing+Non-ECC-RAM aka "Scrub of Death" hat schon einen Bart. Das sollten wir vielleicht endlich hinter uns lassen. Hier nochmal zum Nachlesen: https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

Von Scrub of Death hat niemand was gesagt. Dass dieser Mythos Blödsinn ist, sollte eigentlich jedem klar sein.
Es ging immer nur um die Frage ob ECC das Risiko von unentdeckten Datenverlusten/veränderungen verringern kann oder ob diese ohne ECC möglich sind. Ob man das Risiko als vertretbar oder vermeidbar ansieht und man sich eher als Gustav Gans oder als Pechvogel sieht, muss tatsächlich jeder selber entscheiden.
 
@MrWahoo
Lange kein Lotto mehr gespielt? (ich auch nicht)
Ein Lottoschein hat 10 oder 12 Spielfelder, damit also 10 oder 12 Spiele auf einen Schlag. Dementsprechend reduziert sich die Zeit auf 1/10 oder 1/12.
Ich hatte 14mio Möglichkeiten in Kopf, daher die Rechnung mit den ~10k Jahren.
Ich rechne da ehrlich gesagt nicht nach.
Kann also gut sein, dass es 24mio Spiele sind.(und damit dann ~20k Jahre) Ist am Ende auch egal, weil es um Auftretensverteilung geht und nicht um die konkrete Dauer für den stochastisch garantierten Gewinn.
Von daher sehe ich meine Rechnung in den Grundzügen als korrekt an und die Aussage stimmt am Ende auch, egal ob 10k Jahre oder 20k Jahre für einen theoretisch garantierten Gewinn nötig sind.
Beitrag automatisch zusammengeführt:

Ich weiß aber nicht, ob die Soft Errors bei RAM wirklich zufällig sind und mit der Lotto-Ziehung vergleichbar wären.
Ich sehe das Großteils als wirklich zufällig an, weil im allgemeinen natürliche Effekte als "Zufallszahlengenerator" herangezogen werden.
Effekte durch Strahlung kann man wohl so ansehen.
Auch Störeffekte durch Wärme kann man so ansehen.
Produktionsfehler hingegen nicht unbedingt.
Für Alterungseffekte gibt es die Badewannenkurve und ist damit allgemein auch wieder zufällig, mit variablen Wahrscheinlichkeiten.
Übertakten oder Überbelegung lassen wir mal außen vor.

Am Ende ist der Anteil an stochastischen Fehlern deutlich größer als der der Deterministischen.

Komme ich mit einem 300w Netzteil wie z.b. dieses aus bei 1xRam 1xSSD 5xHDD
Ja, das sollte kein Problem sein. Ich habe glaube nen Enermax 375 oder sowas in der Größenordnung als SFX-L für ein ähnliches System.
Beitrag automatisch zusammengeführt:

Das Thema ZFS+Scrubbing+Non-ECC-RAM aka "Scrub of Death" hat schon einen Bart. Das sollten wir vielleicht endlich hinter uns lassen. Hier nochmal zum Nachlesen: https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/
Wer hat denn vom Scrub of Death gesprochen?
Hole doch nicht immer die alten Kamellen von "ZFS braucht ECC RAM, sonst geht nix" und "nonECC RAM zerstört Daten am laufenden Band" raus.
Bist du in einer Zeitschleife hängen geblieben? Das haben wir alles schon vor Jahren hinter uns gelassen und sind in der Mitte des Jahres 2024 gelandet.

Du hast mich gefragt, was mit den Daten passiert, wenn sie nur so daliegen. Ich habe geschrieben, dass entsprechende Systeme Daten scubben. Da ist ZFS kein Einzelfall, das ist Standard in der IT, seit Jahrzehnten.
Nur so stellt man Datenintegrität sicher.
Am Ende ist es so, dass vermeintlich cold data in solchen Systemen eben nicht cold sind, sondern eigentlich immer irgendwie hot.
Das unterscheidet sie von einfachen Dateisystemen. Da liegen die Daten halt so rum. Ob die Datenintegrität nun gegeben ist oder nicht, weiß man dann, wenn man die Datei öffnet. Hier kommt dann die Katze von Schrödinger ins Spiel. Die Daten sind also kaputt und OK, bis man nachschaut. Und das macht ein Scrub in dem Fall.
 
Zuletzt bearbeitet:
Diese Systeme haben 90% der Zeit nichts zu tun und warten auf den Nutzer. In der Zeit ist nur das OS mit seinen Diensten im RAM. Gelegentlich werden Nutzdaten abgerufen und gelegentlich (eher seltener) werden Nutzdaten empfangen, verarbeitet und gespeichert

Die Annahme, das Ram bleibt leer, ist falsch. Betriebssysteme halten heutzutage gigabyteweise Nutzdaten in ihrem Ram-Cache vor; für Lesen und Schreiben.
Und solange keine andere Anwendung das Ram anfordert, bleiben die Daten für Lesezwecke dann auch da drin.
Das ist egal, ob wir dann über Windows reden, über Linux oder über ein ZFS-basiertes System.

Daher kommt bei mir ebenso ECC zum Einsatz. Der Aufpreis dafür im DIY-Bereich ist gering für die Reduktion der Fehlerwahrscheinlichkeit. Und ich hatte schon korrupte Dateien; Farbblitzer, defekte Zips, etc. etc. . Das war mir eine Lehre, nie mehr geh ich dieses Risiko ein.

Ja, am Ende muss man abwägen. Aber was man nicht tun darf ist, es auf die leichte Schulter zu nehmen.
Andere User oder Magazine mögen zu anderen Bewertungen kommen, aber ich für mich hab mich entschieden "Storage ohne ECC-Funktionalität: nie wieder".

Beispiel: Für einen TV-Mediapc, der nur Kopien von Files vorhält, braucht man es sicher nicht. Für einen Filer der dauerhaft was archivieren soll, IMO schon.
 
Zuletzt bearbeitet:
So, nochmal das ECC Thema, ich pack das mal hier rein.

Ich hab mir überlegt, einen Backupserver zu machen... so jbod mit den ganzen größeren HDDs, die ich noch hab oder so...
Ich hätte noch einen 3570k hier mit 16gb RAM und einen Mainboard mit 8 SATAs.
- Schnell genug wäre die CPU
- RAM reicht auch, andernfalls bekomm ich den ja günstig
- Mainboard hat 8x SATA Onboard (also mal nicht so schlecht), unterstützt 3-Way-Crossfire, sollte also zumindest genug Bifurication können, um NIC, HBA und PCIe SSD aufzunehmen, wobei ich schauen müsste, ob das mit den PCIe SSDs überhaupt so einfach funktioniert.
- Grafik hat die CPU intern, fürs Einrichten wäre Schirm anstecken eigentlich okay.

... ECC gibts halt nicht. Da stellst sich mir die Frage, inwiefern das ein Problem sein könnte... eigentlich mag ich keine Systeme ohne ECC mehr betreiben, weils was wirklich sinnvolles ist.

Alternative wäre ein MC12LE0 mit 5600 und 32gb RAM, kostet halt doch 300€... und besser hinsichtlich PCIe und SATA ist das eigentlich auch nicht...
 
Naja, du möchtest doch dass deine gebackuped Daten so gut und sicher es geht den originalen Daten entsprechen. Damit hast du dir doch die Frage selbst beantwortet.
Warum nicht das MJ11 für einen Backup Server? 8 Sata, CPU schon dabei, billigst PC2133 ECC Rdimm. 1 M.2 Slot ist auch dabei. Ohne Gebastel nur die onboard 1Gbe NIC, aber hey, du willst auf HDDs schreiben…
 
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