Wanneer moet u zich zorgen maken over herhaalde ZFS-checksumcorrecties?

Maak je pas zorgen wanneer checksumfouten terugkeren nadat je de oude nulmeting hebt vastgelegd en gewist, niet alleen omdat een teller niet nul is.

ZFS kan een slecht blok herstellen wanneer redundantie een geldige kopie biedt, maar het herstel verklaart niet waarom de verkeerde gegevens zijn aangekomen. Sla zpool status -v en relevante systeemlogboeken op, controleer back-ups en gebruik vervolgens herhaling, het patroon van getroffen apparaten en een schone scrub om te bepalen of het om een geïsoleerd incident ging of dat de fout nog steeds actief is.

Leg vast wat ZFS heeft gecorrigeerd voordat je iets wist

Sla de volledige poolstatus, het tijdstip van de scrub, de foutentellingen per apparaat en elke lijst met permanente fouten op. Leg ook op hetzelfde moment kernelberichten vast over verbroken verbindingen, time-outs van opdrachten, controllerfouten, machinechecks en onverwachte stroomgebeurtenissen.

Een gedetailleerde uitleg uit de community over herstelde ZFS-checksumtellers en mogelijke oorzaken maakt onderscheid tussen gecorrigeerde blokken en de kabel-, stroom-, controller-, geheugen- of schijffout die ze kan hebben veroorzaakt. Het herstel vormt geen garantie voor de hardwareverbinding.

Controleer voordat je de pool belast of er een andere bruikbare kopie van belangrijke gegevens bestaat. Tellers wissen is alleen verantwoord nadat het bewijsmateriaal is opgeslagen, omdat de volgende beslissing afhangt van de vraag of er echt nieuwe fouten optreden.

Gebruik herhaling en omvang als beslisdrempel

Nadat je de nulmeting hebt opgeslagen, wis je de tellers en voer je één scrub uit tijdens een stabiele periode wat betreft stroom en temperatuur. Als de scrub zonder fouten wordt voltooid en normaal gebruik geen nieuwe fouten oplevert, houd je de situatie in de gaten in plaats van hardware te vervangen vanwege één historisch incident.

Als dezelfde schijf nieuwe checksumfouten krijgt, controleer dan de gegevens- en stroomverbinding, de SMART-geschiedenis, de verbindingsstatistieken en de controllerpoort. Als meerdere schijven tegelijkertijd fouten krijgen, geef dan voorrang aan gedeelde componenten zoals de HBA, backplane, voeding, bekabeling, het geheugen of de systeemstabiliteit.

Elke permanente gegevensfout, herhaalde I/O-fout, poolonderbreking of snel oplopende teller verhoogt de urgentie. Stop niet-essentiële schrijfbewerkingen, werk de back-up bij en isoleer de verdachte laag voordat een nieuwe scrub extra belasting veroorzaakt.

Wijzig één laag en bewijs het resultaat

Schakel het systeem uit en plaats de verdachte gegevens- of stroomkabel opnieuw, vervang deze of verplaats het apparaat naar een bekende goede poort. Vervang niet meerdere lagen tegelijk, anders kun je aan een schoon resultaat niet zien welk onderdeel de uitkomst heeft veranderd.

Voer bij een apparaatspecifiek patroon de test van de schijffabrikant of een gecontroleerde leesbewerking uit nadat je de SMART-geschiedenis hebt bekeken. Test bij een patroon met meerdere apparaten de geheugen- en stroomstabiliteit en controleer de controllerverbinding voordat je ervan uitgaat dat meerdere schijven tegelijk defect zijn geraakt.

De gids voor besturingssystemen voor homeservers helpt je te bepalen waar poolstatus, kernel-logboeken en controllerbeheer zich bevinden op gangbare NAS- en Linux-platforms.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer het herstel onder de oorspronkelijke werklast

Voer na de geïsoleerde reparatie een volledige scrub uit en herhaal daarna de werklast die het probleem eerder aan het licht bracht. Herstel betekent dat de scrub zonder nieuwe checksum-, lees- of schrijffouten wordt voltooid en dat de tellers vlak blijven tijdens een herstart en nog een representatieve periode met werklast.

Vervang een schijf wanneer het bewijs de schijf volgt via een bekende goede verbinding, de SMART-status of zelftests ook verslechteren, of wanneer de schijf nieuwe fouten veroorzaakt nadat bekabeling en stroomvoorziening zijn uitgesloten. Vervang of onderhoud de gedeelde laag wanneer fouten bij een poort, behuizing, controller of stroomgebeurtenis blijven optreden.

Schaal onmiddellijk op bij permanente fouten, een gedegradeerde pool zonder voldoende redundantie of onzekerheid over welke kopie leidend is. Een gecorrigeerd incident is een waarschuwing die je moet onderzoeken; een herhaalde nieuwe correctie is bewijs dat je onderzoek niet kunt uitstellen.

Veelgestelde vragen

Lost zpool clear de oorzaak op? Nee. Het reset de geregistreerde tellers nadat je het bewijsmateriaal hebt opgeslagen; alleen een schone scrub en een stabiele werklast daarna tonen aan dat de onderliggende verbinding geen verkeerde gegevens meer produceert.

Kan ik één gecorrigeerde checksumfout negeren? Beschouw deze als een geregistreerde waarschuwing. Als de fout na het wissen van een nieuwe nulmeting en een schone scrub niet terugkeert, kan monitoring volstaan; herhaling of gerelateerde I/O-fouten vereisen isolatie.

Is de schijf vrijgepleit als het SMART-rapport gezond is? Nee. SMART kan kabel-, controller- en stroomproblemen en sommige apparaatfouten missen. Combineer SMART daarom met de ZFS-omvang, systeemlogboeken, gecontroleerde wissels en scrubs na de reparatie.