När bör du oroa dig för upprepade ZFS-checksumkorrigeringar?
Oroa dig när kontrollsummefel återkommer efter att du har dokumenterat och rensat den gamla baslinjen, inte bara för att en räknare inte är noll.
ZFS kan reparera ett felaktigt block när redundansen tillhandahåller en giltig kopia, men reparationen förklarar inte varför fel data kom fram. Spara zpool status -v och relevanta systemloggar, verifiera säkerhetskopior och använd sedan återkomst, mönstret för berörda enheter och en ren scrub för att avgöra om händelsen var isolerad eller om felet fortfarande är aktivt.
Dokumentera vad ZFS korrigerade innan du rensar något
Spara den fullständiga poolstatusen, tidsstämpeln för scrub, felantal per enhet och eventuell lista över permanenta fel. Samla också in kärnmeddelanden om länkåterställningar, tidsgränser för kommandon, styrenhetsfel, maskinkontroller och oväntade strömhändelser från samma tidpunkt.
En detaljerad förklaring från communityn om reparerade ZFS-kontrollsummeräknare och deras möjliga orsaker skiljer korrigerade block från det kabel-, ström-, styrenhets-, minnes- eller diskfel som kan ha orsakat dem. Reparationen garanterar inte att hårdvaruvägen är felfri.
Bekräfta att det finns en annan användbar kopia av viktiga data innan du belastar poolen. Det är acceptabelt att rensa räknarna först när bevisen har sparats, eftersom nästa beslut beror på om verkligt nya fel uppstår.
Använd återkomst och omfattning som beslutströskel
När baslinjen har sparats rensar du räknarna och kör en scrub under ett stabilt ström- och temperaturfönster. Om scrubben slutförs utan fel och normal användning inte ger några nya fel, bör du övervaka i stället för att byta hårdvara på grund av en enda historisk händelse.
Om samma disk får nya kontrollsummefel granskar du dess data- och strömväg, SMART-historik, länkstatistik och styrenhetsport. Om flera diskar får fel samtidigt prioriterar du gemensamma komponenter som HBA, bakplan, strömförsörjning, kablage, minne eller systemstabilitet.
Alla permanenta datafel, upprepade I/O-fel, poolavstängningar eller snabbt ökande antal fel höjer brådskan. Stoppa icke nödvändiga skrivningar, uppdatera säkerhetskopian och isolera det misstänkta lagret innan ytterligare en scrub ökar belastningen.
Ändra ett lager i taget och bevisa resultatet
Stäng av systemet och sätt tillbaka eller byt den misstänkta data- eller strömkabeln, eller flytta enheten till en känd fungerande port. Byt inte flera lager samtidigt, eftersom ett felfritt resultat då inte visar vilken komponent som ändrade utfallet.
Vid ett enhetsspecifikt mönster kör du disktillverkarens test eller en kontrollerad läsning efter att ha granskat SMART-historiken. Vid ett mönster som omfattar flera enheter testar du minne och strömstabilitet och granskar styrenhetsvägen innan du antar att flera diskar har gått sönder samtidigt.
Guiden till operativsystem för hemmaservrar hjälper dig att hitta var poolhälsa, kärnloggar och styrenhetshantering finns på vanliga NAS- och Linux-plattformar.
Verifiera återställningen under den ursprungliga arbetsbelastningen
Kör en fullständig scrub efter den isolerade reparationen och upprepa sedan den arbetsbelastning som tidigare blottlade problemet. Återställning innebär att scrubben slutförs utan nya kontrollsumme-, läs- eller skrivfel och att räknarna förblir oförändrade genom en omstart och ytterligare en representativ period med arbetsbelastning.
Byt en disk när bevisen följer den genom en känd fungerande väg, när SMART eller självtest också försämras eller när den ger nya fel efter att kablage och ström har uteslutits. Byt eller serva det gemensamma lagret när felen stannar kvar vid en port, ett kabinett, en styrenhet eller en strömhändelse.
Eskalera omedelbart vid permanenta fel, en degraderad pool utan tillräcklig redundans eller osäkerhet om vilken kopia som är den auktoritativa. En korrigerad händelse är en varning som ska utredas; en upprepningsbar ny korrigering är bevis på att utredningen inte kan skjutas upp.
Vanliga frågor
Åtgärdar zpool clear orsaken? Nej. Det återställer registrerade räknare efter att du har sparat bevisen. Endast en felfri scrub och en stabil efterföljande arbetsbelastning visar att den underliggande vägen inte längre producerar felaktiga data.
Kan ett enda korrigerat kontrollsummefel ignoreras? Betrakta det som en registrerad varning. Om det inte återkommer efter en rensad baslinje och en felfri scrub kan övervakning vara rimligt; återkomst eller relaterade I/O-fel kräver isolering.
Frikänner en frisk SMART-rapport disken? Nej. SMART kan missa kabel-, styrenhets- och strömfel samt vissa enhetsfel, så kombinera resultatet med ZFS-omfattning, systemloggar, kontrollerade byten och scrubbar efter reparation.
Rekommenderade produkter
Support och tips
Mer att läsa
Vilken skärmljusstyrka hjälper till att minska ögontrötthet vid långvarig granskning av NAS-filer?
Det finns ingen universell ljusstyrkeprocent; matcha en vit skärm mot rummet, kontrollera bländning, håll texten läsbar och validera under en tidsbestämd granskning.
Så minskar du nackbelastningen när en hemserverkonsol är monterad för lågt
Flytta rutinuppgifter från den låga konsolen eller höj det visuella målet på ett säkert sätt, samtidigt som du håller tangentbordet lägre och testar en...
Varför känns mina ögon trötta efter att ha övervakat en ljusstark serverpanel på natten?
Trötthet vid nattinstrumentpanelen beror ofta på en kombination av felaktig ljusstyrka, bländning, långvarigt fokus och minskat blinkande; justera en faktor i taget och testa...
