Waarom volgen NAS-scrubfouten één controllerpoort bij verschillende schijven?

Scrubfouten die via verschillende schijven steeds dezelfde controllerpoort volgen, wijzen meestal op het gedeelde pad en niet op het opslagmedium van de schijven.

Een scrub leest een brede set blokken en kan fouten aan het licht brengen die bij normaal dagelijks gebruik nooit worden bereikt. Als verschillende schijven waarvan bekend is dat ze goed werken alleen fouten ontwikkelen wanneer ze via dezelfde poort zijn aangesloten, behoren het controllerkanaal, de connector, kabel, backplane-lane, expanderroute, stroomvoorziening, firmware en koeling rond dat pad tot de gemeenschappelijke componenten. De diagnose moet aantonen dat de fout de poort volgt, terwijl de schijfidentiteit, tijdstempels en het fouttype behouden blijven.

Bevestig dat de fout de poort volgt en niet de schijfnaam

Noteer de serienummers van de schijven, stabiele apparaat-ID's, de controllerpoort of HBA-PHY, kabel, sleuf, poollid en de lees-, schrijf- en checksomtellers voordat de volgende scrub begint. Vertrouw niet uitsluitend op veranderende namen zoals /dev/sdX.

De probleemoplossingsflow voor schijven van TrueNAS benadrukt dat u pool- en SMART-bewijs moet verzamelen voordat u fouten wist of een apparaat vervangt.

Vraag na het verwisselen terwijl het systeem is uitgeschakeld of de fout de schijf, sleuf, kabel of controllerpoort volgt. Wijzig per test slechts één component, zodat het resultaat interpreteerbaar blijft.

Scheid checksomfouten van de scrub van lees- en schrijffouten van de schijf

Sla het volledige scrubresultaat en de tellers per apparaat op. Een checksommismatch, commandotime-out, onleesbare sector en mislukte schrijfactie vertegenwoordigen verschillende foutlagen.

Oracle documenteert dat een ZFS-scrub de checksums van actieve gegevens verifieert, terwijl de poolstatus afzonderlijk lees-, schrijf- en checksumfouten voor elk apparaat rapporteert.

Als checksumfouten toenemen zonder mediumfouten en één fysiek pad volgen, verdenk dan gegevensbeschadiging tussen het geheugen en de schijf of een instabiele verbinding. Als leesfouten de schijf naar andere poorten volgen, wordt de schijf waarschijnlijker als oorzaak.

Breng de schijf in kaart naar de exacte controller en verbinding

Volg het stabiele schijfpad via de hostcontroller, het PCI-adres, de SAS-expander of SATA-poort, behuizing, kabel en sleuf. Sla deze koppeling op voordat u hardware verplaatst.

De apparaatweergave van lspci identificeert de PCI-opslagcontroller onafhankelijk van bestandsysteem- en poolnamen. Dat helpt om één defect controllerpad te onderscheiden van een schijf die alleen een nieuwe apparaatnaam heeft gekregen.

Vermeld voor een HBA ook de PHY- en expanderinformatie, indien beschikbaar. Twee sleuven aan de voorkant kunnen dezelfde mini-SAS-kabel of expanderlane delen, ook al toont de interface ze als afzonderlijke sleuven.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controleer SATA- of SAS-linkresets tijdens de scrub

Monitor het kernel-log vanaf het moment dat de scrub begint. Let op harde resets, COMRESET-fouten, link-down-gebeurtenissen, commandotime-outs, protocolfouten en wijzigingen in de onderhandelde snelheid op het getroffen pad.

De Linux libATA-handleiding beschrijft linkresets en foutherstel per poort. Dit laat zien waarom herhaalde meldingen die aan één ATA-poort zijn gekoppeld sterker bewijs vormen dan een algemene poolwaarschuwing.

Bewaar de eerste transportmelding. Latere bestandssysteemfouten kunnen slechts gevolgen zijn van het verlies van communicatie tussen de controller en de schijf tijdens een leesactie.

Vergelijk CRC- en commandotime-outtellers van de verbinding

Leg SMART-attributen en -logs voor elke schijf vast vóór en na één scrub. Houd bij of de tellers voor interface-CRC- of commandotime-outfouten alleen op het getroffen pad toenemen.

Unraid legt uit dat UDMA-CRC-fouten tussen de schijf en controller optreden. Daarbij zijn meestal kabels, connectoren, bekabeling of de controllerverbinding de oorzaak, en niet schade aan de platters.

Historische CRC-totalen identificeren de huidige component niet. Noteer de ruwe teller, voer één afgebakende test uit en controleer alleen of de waarde is toegenomen.

Voer schijftests afzonderlijk van de scrubbelasting uit

Voer ondersteunde korte en uitgebreide SMART-tests uit wanneer de pool verder rustig is en de gegevens zijn beschermd. Plan geen volledige SMART-test tegelijk met een andere scrub of reconstructie.

De smartctl-referentie van Debian maakt onderscheid tussen interne zelftests en foutlogs van de schijf enerzijds en bestandssysteemverificatie aan de hostzijde anderzijds.

Een schijf die een interne test doorstaat maar alleen op één controllerpoort fouten veroorzaakt, versterkt de hypothese van een probleem in het pad. Dit bewijst niet dat de schijf perfect is, dus blijf monitoren nadat de poort is gewijzigd.

Vervang één gedeelde component en herhaal een afgebakende scrub

Verplaats met actuele back-ups en terwijl de server is uitgeschakeld een schijf waarvan bekend is dat deze goed werkt door het verdachte pad, of vervang één kabel terwijl u de overige variabelen gelijk houdt. Verplaats niet alle schijven tegelijk.

De ZimaSpace-handleiding over een uitgevallen schijf versus een defecte schijfsleuf biedt de bijbehorende methode voor gecontroleerd verwisselen. Dit artikel past die logica specifiek toe op scrubfouten die herhaaldelijk dezelfde controllerpoort volgen.

Stop de scrub en geef gegevensbescherming prioriteit als fouten snel toenemen, meerdere schijven op dezelfde controller worden gereset, de pool degradeert of toepassingen melden dat bestanden beschadigd zijn. Het probleem is pas opgelost nadat hetzelfde poortpad herhaaldelijk een scrub en normale I/O heeft voltooid zonder nieuwe fouten.