Hallo zusammen,

ich habe in meinem bestehenden und fehlerlos laufenden System folgende Änderungen durchgeführt:

Array: 2x4TB mit Data+Parität (unverändert)

Cache:

bisher lief hier eine nvme mit 500gb.

Ich wollte nun daraus ein Raid1 machen.

Daher habe ich mir 2 baugleiche Samsung NVMEs gekauft.

Die alte wollte ich austauschen, damit zwei gleichschnelle das Raid bilden.

Ich bin wie folgt vorgegangen:

1. 1. Samsung NVME eingebaut

2. Raid1 aufgebaut

3. Alte Nvme (Intenso) ausgebaut (bis hierhin alles fehlerlos)

4. 2. Samsung NVME eingebaut

5. Array gestarte und beim Aufbau des Raids ist hier dann eine Fehlermeldung erschienen.
   
   nvme0n1 → 13.419 Write Errors + 352 Flush Errors ❌
   nvme1n1 → 0 Fehler ✅
   
   Daraufhin habe ich den Fehlerspeicher resettet und nun erscheint es als healthy und es sind keine weiteren Fehler aufgetreten.
   
   Hat jemand eine Idee woher die Fehler stammen und kann ich nun einfach so weiterlaufen lassen oder muss ich mir um die Fehler Gedanken machen?

Hier noch ein Bild vom Build:

Danke für eure Hilfe!

Edited October 5Oct 5 by simon262

Hallo Simon,

die Zahlen, die du gesehen hast, sind vermutlich nur die Fehlerzähler, die btrfs pro Gerät führt (Write-, Read-, Flush-Fehler). Sie zählen, wie oft der Kernel einen Schreib- bzw. Flush-Befehl an diese NVMe nicht loswurde. Wenn Write- und Flush-Fehler gleichzeitig und in dieser Menge auf einem Gerät hochgehen, hat die NVMe in dem Moment typischerweise für eine Weile gar nicht mehr geantwortet (kurzer Aussetzer/Reset des Laufwerks), es sind vermutlich keine einzelnen kaputten Sektoren. Bei dir ist das genau während des Umbaus auf RAID1 passiert, also unter Dauerlast.

Weil der Pool ein RAID1 ist, hat btrfs in der Zeit einfach auf die andere NVMe weitergeschrieben. Verloren ist dadurch vermutlich nichts, aber die Kopie auf nvme0n1 kann für diesen Zeitraum unvollständig sein. Das Zurücksetzen der Zähler ändert daran nichts, es löscht nur die Anzeige. Darum zwei Dinge:

1. Scrub laufen lassen: Main → auf "Cache" klicken → Abschnitt "Scrub Status" → Scrub. Das geht bei laufendem Array. Der Scrub liest beide Kopien, vergleicht sie über die Prüfsummen und repariert eine veraltete Kopie von der guten Seite. Am Ende steht im Status, ob Fehler gefunden und korrigiert wurden. "no errors found" heisst: beide Seiten sind identisch, alles gut.

2. Ursache finden: Tools → Diagnostics und das ZIP hier anhängen. Falls du seit dem Vorfall neu gestartet hast, ist der Syslog von damals leider weg (er liegt im RAM). Dann stell bitte Settings → Syslog Server → "Mirror syslog to boot drive" auf Yes, damit beim nächsten Mal etwas da ist. Schau ausserdem bei der betroffenen NVMe unter Main → Gerät anklicken → Attributes nach "Media and Data Integrity Errors", "Error Information Log Entries", "Unsafe Shutdowns" und "Warning Comp. Temperature Time". Stehen die alle auf 0, ist die NVMe selbst vermutlich in Ordnung, und der Aussetzer kam eher von der Verbindung (M.2-Slot, Stromsparzustand des Laufwerks) als vom Chip.

Weiterlaufen lassen kannst du den Pool, wenn der Scrub ohne Fehler durch ist. Kommen die Zähler wieder hoch, dann mit dem gespiegelten Syslog melden, dann sieht man, was die NVMe in dem Moment gemeldet hat.

Edited October 17Oct 17 by UnraidSecretaryOffice

Hi UnraidSecretaryOffice :-),

vielen Dank für deine Antwort.

Ich habe die Schritte befolgt.

1. Der Scrub lief ohne Fehler durch.

2. Die 4 der von dir genannten Attributes stehen 0, jedoch stehen bei beiden NVMEs die "Error Information Log Entries" auf 30.000 bzw. 60.000 (!!). Ich nehme an, das ist kein gutes Zeichen.

3. Die Zip habe ich heruntergeladen und hier angehängt.

So wie ich es beurteilen kann, läuft das System zumindest stabil. Ich merke keine Einschränkungen. Dennoch bin ich aufgrund der hohen Fehleranzahl natürlich verunsichert.

Vielen Dank für deine Hilfe. Ich weiß es sehr zu schätzen.

unraid-diagnostics-20261022-1120.zip

Edited October 22Oct 22 by simon262

Die 30.000 und 60.000 sind nur die Länge des Fehlerprotokolls und alle Einträge sind vom selben Typ, “Invalid Field in Command”, also abgelehnte Verwaltungsbefehle (Abfragen nach etwas, das die Firmware nicht kennt), keine Lese- oder Schreibfehler. Kann man ignorieren.

Dein Scrub heute Vormittag ohne Fehler auf beiden Geräten, und seit dem 17. Oktober kein einziger relevanter Fehler im Log. Sieht also gut aus würde ich behaupten.

Zwei Dinge am Rande: die beiden nvme1 und nvme0 melden viele Power Cycles und viele Unsafe Shutdowns bei relativ wenig Betriebsstunden. Unraid startet man nicht so häufig, das stammt wohl aus einem früheren Leben der SSDs (gebraucht gekauft, oder vorher in einem Notebook?). Und falls die Aussetzer vom Anfang wiederkommen: Beide NVMes laufen bei dir mit ASPM L1 (PCIe-Stromsparen). Das wäre dann mein erster Verdächtiger, testweise pcie_aspm=off in der Syslinux-Konfiguration. Solange das nicht wieder passiert kannst es aber so lassen.

Und Settings → Syslog Server → "Mirror syslog to boot drive" kannst du wieder auf No stellen. Und das Problem scheint vorerst gelöst denke ich.

Ich danke dir vielmals für die Rückmeldung. Das hat mir sehr geholfen und ich bin nun nicht mehr besorgt um mein System.

Die nvmes habe ich tatsächlich gebraucht gekauft, da kommen die vielen shutdowns her. Mein System läuft normalerweise 24/7. Ich musste das System jedoch auch selbst einige Male durch einen hard reset neu starten, da aus irgendwelchen Gründen mein Unraid bei einem Neustart hängen bleibt. Es bleibt mir dann nichts anderes übrig, als den Stecker zu ziehen. Die Neustarts waren jeweils aufgrund von System Updates notwendig.

Ich lasse nun also erstmal alles so, wie es grad ist. Danke nochmals!

Gerne und ich hoffe, dass es jetzt auch stabil bleibt. Du könntest eine Antwort als Lösung markieren. Dann sehen andere in der Forum-Übersicht, dass es hier keine Hilfe mehr braucht. Und falls jemand mal dasselbe Problem hat, kommt er zügig zum richtigen Bereich.