Scrub-Fehler, die bei verschiedenen Laufwerken demselben Controller-Port folgen, deuten in der Regel eher auf den gemeinsamen Übertragungsweg als auf die Aufzeichnungsmedien der Laufwerke hin.
Ein Scrub liest eine große Anzahl von Blöcken und kann Fehler aufdecken, die beim normalen täglichen Zugriff nie erreicht werden. Wenn verschiedene nachweislich fehlerfreie Laufwerke nur dann Fehler entwickeln, wenn sie über denselben Port verbunden sind, gehören zu den gemeinsamen Komponenten der Controller-Kanal, der Anschluss, das Kabel, die Backplane-Leitung, die Expander-Strecke, die Stromversorgung, die Firmware und die Kühlung entlang dieses Pfads. Die Diagnose muss belegen, dass der Fehler dem Port folgt, und dabei Laufwerksidentität, Zeitstempel und Fehlertyp bewahren.
Bestätigen, dass der Fehler dem Port und nicht dem Laufwerksnamen folgt
Notieren Sie vor dem nächsten Scrub die Seriennummern der Laufwerke, stabile Geräte-IDs, den Controller-Port oder HBA-PHY, das Kabel, den Einschub, das Pool-Mitglied sowie die Lese-, Schreib- und Prüfsummenzähler. Verlassen Sie sich nicht ausschließlich auf wechselnde Namen wie /dev/sdX.
Der Ablauf zur Laufwerksfehlerbehebung von TrueNAS legt Wert darauf, Pool- und SMART-Nachweise zu sammeln, bevor Fehler gelöscht oder ein Gerät ersetzt wird.
Fragen Sie nach einem Tausch im ausgeschalteten Zustand, ob der Fehler dem Laufwerk, Einschub, Kabel oder Controller-Port folgt. Ändern Sie pro Test nur eine Komponente, damit das Ergebnis interpretierbar bleibt.
Scrub-Prüfsummenfehler von Lese- und Schreibfehlern des Laufwerks unterscheiden
Speichern Sie das vollständige Scrub-Ergebnis und die Zähler für jedes Gerät. Eine Prüfsummenabweichung, ein Befehls-Timeout, ein nicht lesbarer Sektor und ein fehlgeschlagener Schreibvorgang stehen für unterschiedliche Fehlerebenen.
Oracle dokumentiert, dass ein ZFS-Scrub die Prüfsummen aktiver Daten verifiziert, während der Pool-Status Lese-, Schreib- und Prüfsummenfehler für jedes Gerät separat meldet.
Wenn Prüfsummenfehler ohne Medienfehler zunehmen und einem physischen Übertragungsweg folgen, sind Datenbeschädigungen zwischen Arbeitsspeicher und Laufwerk oder ein instabiler Transportweg wahrscheinlich. Wenn Lesefehler dem Laufwerk über verschiedene Ports hinweg folgen, wird das Laufwerk als Ursache wahrscheinlicher.
Die Festplatte dem exakten Controller und der Verbindung zuordnen
Verfolgen Sie den stabilen Laufwerkspfad über den Host-Controller, die PCI-Adresse, den SAS-Expander oder SATA-Port, das Gehäuse, das Kabel und den Einschub. Speichern Sie die Zuordnung, bevor Sie Hardware umstecken.
Die Geräteansicht von lspci identifiziert den PCI-Speichercontroller unabhängig von Dateisystem- und Pool-Namen. Das hilft dabei, einen fehlerhaften Controller-Pfad von einem Laufwerk zu unterscheiden, das lediglich einen neuen Gerätenamen erhalten hat.
Beziehen Sie bei einem HBA nach Möglichkeit PHY- und Expander-Informationen ein. Zwei vordere Einschübe können sich ein Mini-SAS-Kabel oder eine Expander-Leitung teilen, obwohl die Benutzeroberfläche sie als getrennte Steckplätze anzeigt.
SATA- oder SAS-Link-Resets während des Scrubs prüfen
Überwachen Sie das Kernel-Protokoll ab dem Moment, in dem der Scrub beginnt. Achten Sie auf harte Resets, COMRESET-Fehler, Verbindungsabbrüche, Befehls-Timeouts, Protokollfehler und Änderungen der ausgehandelten Geschwindigkeit auf dem betroffenen Pfad.
Der Linux-libATA-Leitfaden beschreibt portbezogene Link-Resets und Fehlerbehandlung. Das zeigt, warum wiederholte Meldungen zu einem einzelnen ATA-Port ein stärkerer Hinweis sind als eine allgemeine Pool-Warnung.
Bewahren Sie die erste Transportmeldung auf. Spätere Dateisystemfehler können lediglich Folgen davon sein, dass der Controller während eines Lesevorgangs die Kommunikation verloren hat.
Schnittstellen-CRC- und Befehls-Timeout-Zähler vergleichen
Erfassen Sie die SMART-Attribute und -Protokolle für jedes Laufwerk vor und nach einem Scrub. Beobachten Sie, ob die Zähler für Schnittstellen-CRC-Fehler oder Befehls-Timeouts nur auf dem betroffenen Pfad zunehmen.
Unraid erklärt, dass UDMA-CRC-Fehler zwischen Laufwerk und Controller auftreten und häufig auf Kabel, Anschlüsse, Verkabelung oder die Controller-Verbindung hindeuten, nicht auf eine Beschädigung der Plattenoberfläche.
Historische CRC-Gesamtwerte identifizieren nicht die aktuell fehlerhafte Komponente. Notieren Sie den Rohwert, führen Sie einen begrenzten Test durch und prüfen Sie lediglich, ob der Wert gestiegen ist.
Laufwerkstests getrennt vom Scrub-Arbeitsaufkommen durchführen
Führen Sie unterstützte kurze und umfassende SMART-Tests durch, wenn der Pool ansonsten wenig ausgelastet ist und die Daten geschützt sind. Planen Sie keinen vollständigen SMART-Test gleichzeitig mit einem weiteren Scrub oder Wiederaufbau.
Die smartctl-Referenz von Debian unterscheidet laufwerksinterne Selbsttests und Fehlerprotokolle von der dateisystemseitigen Überprüfung durch den Host.
Ein Laufwerk, das einen internen Test besteht, aber nur an einem Controller-Port Fehler erzeugt, stützt die Hypothese eines fehlerhaften Pfads. Das beweist nicht, dass das Laufwerk fehlerfrei ist. Überwachen Sie es daher weiter, nachdem der Port gewechselt wurde.
Eine gemeinsam genutzte Komponente tauschen und einen begrenzten Scrub wiederholen
Wenn die Backups aktuell sind und der Server ausgeschaltet ist, führen Sie ein nachweislich fehlerfreies Laufwerk durch den verdächtigen Pfad oder ersetzen Sie ein Kabel, während die übrigen Variablen unverändert bleiben. Tauschen Sie nicht alle Laufwerke gleichzeitig um.
Der ZimaSpace-Leitfaden zu einem ausgefallenen Laufwerk im Vergleich zu einem fehlerhaften Einschub beschreibt die entsprechende Methode des kontrollierten Tauschs. Dieser Artikel wendet dieselbe Logik speziell auf Scrub-Fehler an, die wiederholt einem einzelnen Controller-Port folgen.
Beenden Sie den Scrub und priorisieren Sie den Datenschutz, wenn die Fehler schnell zunehmen, mehrere Laufwerke am selben Controller zurückgesetzt werden, der Pool degradiert oder Anwendungen beschädigte Dateien melden. Das Problem ist erst gelöst, wenn derselbe Portpfad wiederholt einen Scrub und normale I/O ohne neue Fehler abschließt.
Support & Tipps
Mehr zum Lesen

Kann Plex eine GPU mit einem anderen Docker-Container gemeinsam nutzen?
Plex und ein weiterer Container können häufig auf dieselbe GPU zugreifen, aber du musst die Treiberunterstützung, die Gerätezuordnung, die Auslastung der Video-Engine, den Speicher...

So erkennst du, ob ein Plex-Fehler vom Client oder vom Server verursacht wird
Reproduziere dasselbe Element auf einem anderen Client, vergleiche den Sitzungspfad und sammle Serverbelege erst, nachdem der Geltungsbereich dir gezeigt hat, wo der Fehler tatsächlich...

So konfigurierst du den Plex-Cache und den temporären Transcodierungs-Speicher
Schütze den persistenten Plex-Zustand, indem du temporäre Transcodierungsdateien auf geeignetem lokalem Speicher ablegst, und überprüfe anschließend die Bereinigung, den freien Speicherplatz und das Verhalten...

