Unraid oder TrueNAS für 4x 18TB Storage Only

[Khorneflakes]

Danke @.fF , den Post von Matt Ahrens wollte ich auch gerade raussuchen. iXsystems, die TrueNAS entwickeln, was bekanntlich auf ZFS setzt, sieht es auch nicht anders. Und mir würde auch kein Grund einfallen, warum man das anders sehen sollte oder warum das nicht korrekt sein sollte.

Wie ich sagte: Risikobewertung. Aber nachher dann nicht jammern. Auch dazu gibts genug Beiträge im Netz.

 

[Anonymous209]

ok, also ZFS verwenden, aber ohne gewähr dass es ohne EEC läuft 🤣 das wäre dann also das letzte FS was ich nutzen würde

 

[kieleich]

ECC habe ich nicht
ZFS nutze ich nicht

Memtest ständig (per Linux Kernelparameter bei jedem Boot)

Auch langzeit memtest mal ausprobiert (gigabytes zufalldaten in eine ramdisk, nach x Tagen schauen obs noch stimmt)

Ergebnis = ich habe noch nie, ein gekipptes Bit fest gestellt

Das auf Desktop Hardware, mit Vollbestückung

Ursache von Korruption, meiner Erfahrung nach... Software die korrupte Daten schreibt... so wie schlicht und einfach Bugs (auch im Dateisystem oder Kernel), nur da hilft auch ECC nichts

Also wer Memtest gemacht hat der hat da wenig zu befürchten. Muss jeder selbst wissen ECC war einfach nie eine Option für mich da meine Hardware es gar nicht unterstützt

Bei klassischem RAID 5 sind auch regelmäsige Checks auf Parity Mismatch wichtig. Ist die Parity einmal falsch, bleibt sie auch nach weiteren Writes falsch.

 

[Anonymous209]

ich kenne nach 30 jahren NTFS auch keine bitfehler an denen ich nicht selbst schuld wäre. man kann auch 1x am tag das NAS neustarten und somit die daten im RAM erneuern.

und synology schaffe es auch iwie ohne EEC...

 

[Banned]

Memtest ständig (per Linux Kernelparameter bei jedem Boot)

Ein Durchgang memtest86 (also mit vier Durchläufen) dauert mehrere Stunden (je nach Menge an RAM mehr oder weniger).

Du meinst wahrscheinlich so einen einfachen Speichertest, der ist bedingt aussagekräftig.

Auch langzeit memtest mal ausprobiert (gigabytes zufalldaten in eine ramdisk, nach x Tagen schauen obs noch stimmt)

Die Daten im RAM werden alle paarhundert ms refresht. Somit wird die bloße Dauer wahrscheinlich wenig Einfluss haben, würde ich vermuten. Memtest86 prüft hier auch eher in kurzem Abstand, ob die Daten noch korrekt sind, was aber auch der Konstitution als Test (der eben nicht ewig dauern soll) geschuldet sein kann.

Ergebnis = ich habe noch nie, ein gekipptes Bit fest gestellt

Die Anzahl an Bitfehlern hängt auch sehr mit der Menge an Daten zusammen, die verarbeitet werden. Große Serveranlagen, die mehrere TBs am Tag verarbeiten, haben z.B. mehrere Bit-Fehler pro Tag.

Als Privatperson ist das Risiko hingegen recht überschaubar, und ein gekipptes Bit bedeutet nicht automatisch einen (durch den Nutzer) wahrnehmbaren Fehler.


Ein ganz wesentlicher Faktor wird beim Thema ECC-RAM aber oft vergessen: Dabei werden die Daten nicht nur im RAM gegen 1-Bit-Fehler abgesichert, sondern auch auf dem Weg von bzw. zur CPU. Deshalb ist on-Die-ECC - wie bei DDR5 verwendet - auch kein richtiger ECC für den RAM.

und synology schaffe es auch iwie ohne EEC...

Die haben auch Geräte mit im Angebot:

https://geizhals.de/?cat=hdxnas&xf=1172_Synology~14996_ECC~2659_ohne

Aber der 0815-Nutzer wird eben ohne abgespeist. Hauptsächlich liegt das auch daran, dass Intel ECC-RAM-Unterstützung nur für wenige CPUs freischaltet.

Ich finde es ja bei Synology löblich, dass sie Btrfs mittlerweile für viele Modelle anbieten und das Thema Datenkorruption auch offen behandeln:

https://blog.synology.com/ger/was-ist-data-scrubbing-2-mechanismen-zur-datenbereinigung/

 

[kieleich]

Ein Durchgang memtest86 (also mit vier Durchläufen) dauert mehrere Stunden (je nach Menge an RAM mehr oder weniger).

Klar und natürlich lasse ich den auch ab und zu mal laufen, aber das sind alles Kurzzeit Tests.

Du meinst wahrscheinlich so einen einfachen Speichertest, der ist bedingt aussagekräftig.

Viele machen ja nicht mal den und dann reicht, ein falsches BIOS Setting. Dann brennt die Hütte aber wirklich.

Die Daten im RAM werden alle paarhundert ms refresht.

Klar, aber es ist doch so, wenns kippt dann kippt's. Der Refresh kann ja auch nicht prüfen was richtig war.

Mein Rechner läuft eben nicht jahre lang am Stück so kann ich den ultra-lange-zeit Test nicht machen.

Das was im Rahmen, meiner Möglichkeiten zu testen war, habe ich getestet. Kurzum es ist einfach, nichts fest stellbar und so soll es ja auch sein!

Auch bei ECC muss man testen und kann Fehler nicht einfach ignorieren, wenns mit ECC wackelt muss man tauschen.

Hätte ich reproduzierbar Bitfehler selbst nur 1x die Woche oder so würde das Ding hochkant fliegen. Aber da ist einfach nichts

Die Anzahl an Bitfehlern hängt auch sehr mit der Menge an Daten zusammen, die verarbeitet werden. Große Serveranlagen, die mehrere TBs am Tag verarbeiten, haben z.B. mehrere Bit-Fehler pro Tag.

Das habe ich eben oft gehört aber noch nie reproduzieren können

Beim RAID gibt es ja ein ähnliches Argument, es wäre ein Fehler alle X Terabytes und deswegen könne man raid5 z.B. gar nicht mehr empfehlen. Aber auch hier, habe ich dies noch nie reproduzieren können.

 

[Banned]

Das habe ich eben oft gehört aber noch nie reproduzieren können

Wenn du kein System mit ECC-RAM hast, werden die Fehler doch auch gar nicht geloggt bzw. es gibt keine Log-Funktion (die gibt es nicht mal auf allen Plattformen mit ECC). Somit ist es hier schon mal schwerer, überhaupt die Fehler zu erkennen. Oder wie spürst du Bit-Fehler im normalen Windows bzw. Linux-Betrieb o.Ä. auf? Ohne Log kriegst du davon eben sehr wahrscheinlich gar nichts mit. Irgendwelche Tests, die du machst, sind doch nur ein kleiner Bruchteil von den Daten, die dein Rechner im Jahr so verarbeitet. Wenn du dann als Privatnutzer im Jahr vielleicht 0-3 Bit-Errors oder so hast, muss man die erst mal mitkriegen ohne Log, sofern es welche gab.

Wenn irgendeine Serverfarm am Tag etliche TB verarbeitet, ist das einfach was anderes, und die haben eben Logs.

Beim RAID gibt es ja ein ähnliches Argument, es wäre ein Fehler alle X Terabytes und deswegen könne man raid5 z.B. gar nicht mehr empfehlen. Aber auch hier, habe ich dies noch nie reproduzieren können.

Festplatten haben eine UBER (unrecoverable bit error rate) - wird vom Hersteller angegeben; laut dieser tritt statistisch nach x gelesenen Bits ein unkorrigierbarer Bit-Fehler auf. Da Festplatten immer größer werden, die UBER aber nicht, gibt es hier schon eine gewisse zunehmende Problematik.
Das Problem beim RAID5 gibt es aber eigentlich nur beim Rebuild bzw. Resilvering - soweit ich das sehe: tritt hier so ein Fehler auf, kann eben nicht aus der Redundanz korrigiert werden, da bereits eine Festplatte ausgefallen ist und RAID5 eben nur eine Parität hat.

 

[Khorneflakes]

(die gibt es nicht mal auf allen Plattformen mit ECC)

Ganz genau so ist es.

Bei vielen Servern wirst du nie irgendeine Meldung sehen, und wenn du dann doch eine siehst, dann ist das sowas wie "ECC error threshold exceeded".

Heißt: Die Hardware ist schon so ausgelegt, dass eine gewisse Anzahl an Fehlern erwartet wird. Fehler werden nicht gemeldet, wenn die korrigiert werden ist das auch erstmal nicht weiter relevant. Erst wenn ein Schwellwert überschritten wird, dann wird das gemeldet. Oder bei Multi-Bit-Fehlern, die ECC nicht mehr korrigieren kann.

Da wird dann davon ausgegangen, dass das nicht mehr normal ist und man das betroffene DIMM mal austauschen sollte.

 

[alturismo]

Unraid lohnt sich für mich nicht wirklich, da ich weder VM/Docker via Unraid nutzen werde, noch die Flexibilität bzgl. Speicher-Erweiterung benötige. Da spare ich mir die Lizenz für ein anderes Projekt auf.

genau, da Unraid ja auch VM, Docker und LXC Host wäre ... wäre das sinnfrei in einer VM laufen zu lassen

 

[Bohnenhans]

Und eben nicht korrumpierte als korrumpiert erkannt. Am Ende ist das aber vermutlich eher ein minimales Risiko.

Ergänzung (27. Juli 2024)

Generell ist ZFS aber wesentlich RAM-lastiger als andere FS.

Zfs erkennt dann nur dass die berechnete checksumme anders ist als die auf der hdd und macht gar nichts ausser einen crc error anzuzeigen

 

[herrhannes]

Joa, und wenn es zu viele sind, dann halt die entsprechende Platte failen. Wenn du dann ein Resilver machst, kommt Unfug raus.