Warum folgen NAS-Scrub-Fehler über verschiedene Laufwerke hinweg immer demselben Controller-Port?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

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

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.