Hur länge bör du vänta innan du kallar en RAID-återuppbyggnad för fastlåst?

Anse en RAID-återuppbyggnad som fastnad endast när antalet bearbetade block slutar öka vid upprepade kontroller och loggarna inte visar någon avsiktlig paus, prioriteringsbegränsning, köad fas eller återhämtningsbar omförsök. Förfluten tid ensam är otillräcklig.

Stora arrayer kan spendera timmar i ett långsamt område, ändra hastighet kraftigt under applikationsbelastning eller pausa mellan rekonstruktion och verifiering. Fastställ rörelse med räknare och loggar innan du ingriper, eftersom att stoppa eller återmontera en array kan skapa större risk än att vänta.

Använd framstegsdifferens, inte en enda procentandel

Registrera exakt antal bearbetade block, procentandel, hastighet och uppskattad sluttid vid fasta intervaller. En återuppbyggnad pågår när blockantalet ökar, även om den avrundade procentandelen förblir oförändrad. På multi-terabyte-arrayer kan en visad tiondel av en procent representera en stor mängd arbete.

Kontrollera styrenheten eller operativsystemet från samma gränssnitt varje gång. Olika instrumentpaneler kan cachelagra status eller rapportera olika faser. En framstegsindikator som verkar frusen medan blockräknare ökar är ett övervakningsproblem, inte en fastnad återuppbyggnad.

Uppskatta en lokal baslinje istället för en universell timeout

Det finns inget enda säkert antal timmar. Återuppbyggnadstiden beror på använd kapacitet, RAID-konfiguration, enhetshastighet, fel, styrenhetspolicy, bakgrundslast och om implementationen kopierar alla block eller endast tilldelade områden.

Använd den första stabila timmen för att uppskatta ett ungefärligt intervall och jämför sedan senare intervaller. En mycket långsam mdadm-återsynkroniseringshastighet kan bero på arbetsbelastning, justering, länkbeteende eller en kämpande enhet; rätt diagnos kräver mer än att bara höja en hastighetsgräns.

Sök efter en avsiktlig paus eller en ny fas

Vissa system begränsar återhämtning för att skydda förgrunds-I/O, pausar skanningar under återuppbyggnad, väntar på en reservtilldelning eller övergår från återuppbyggnad till paritetsinitiering eller konsistenskontroll. Etiketten kan förbli ”återuppbyggning” medan den aktiva uppgiften ändras.

Granska schemalagt underhåll, ströminställningar, temperaturgränser, återuppbyggnadsprioritet och applikationstrafik. Om hastigheten ökar när belastningen i förgrunden minskar är arrayen resursbegränsad snarare än fast.

Upprepade läsfel skapar ett verkligt stopp

En källdisk kan spendera lång tid på att försöka igen en svag sektor, vilket orsakar genomströmning att kollapsa nära samma blockintervall. Om kontrollern slutligen rapporterar en oåterkallelig läsning kan återuppbyggnaden avbrytas eftersom redundans inte kan rekonstruera den regionen.

En återuppbyggnad stoppad av läsfel visar varför det sista lyckade blocket och kärnfelet omedelbart efter är viktiga. Starta inte om en återställning som misslyckas på samma adress utan att skydda data och undersöka källmedlemmen.

En nollhastighet med loggaktivitet kan vara ett omförsök

En visad hastighet på noll kan uppstå under kommandoförsök, enhetsåterställningar, felåterställning, metadatauppdateringar eller ett tillfälligt uppehåll. Övervaka diskens upptid, ködjup, kontrollerhändelser och kärnmeddelanden. Upprepade återställningar eller timeout är inte hälsosam framsteg.

En återställning som upprepade gånger avbryts visar också att inte varje stopp har ett uppenbart SMART-fel. Fånga den exakta punkten och alla loggar istället för att anta att en ny disk eller högre hastighetsinställning löser det.

Använd en praktisk stallbeslutstabell

Kräv bevis från minst två oberoende signaler innan du kallar ombyggnaden avstannad: ingen räknarrörelse plus ett fel, avbrutet tillstånd eller ihållande identisk stoppunkt.

Vad man ska göra innan du startar om något

1. Spara arraydetaljer, medlemsserier, räknare för bearbetade block och hela händelseloggen.
2. Minska icke nödvändig applikations-I/O och bekräfta att målet och källdiskarna fortfarande är upptäckta.
3. Kontrollera SMART-medieindikatorer och länkåterställnings- eller CRC-räknare på varje aktiv källa.
4. Bekräfta att det inte finns något pausat tillstånd, temperaturgräns, prioritetspolicy eller köad verifieringsfas.
5. Eskaler till backup, imaging eller återställning när samma oläsbara intervall stoppar upprepade försök.

Använd inte stop, assemble, force-online eller metadata-clear kommandon förrän arrayens tillstånd och exakt implementering är kända.

Jämför framsteg under ett tyst intervall

Ett användbart test för avstannande behöver ett kontrollerat observationsfönster. Pausa stora överföringar och schemalagda jobb, och registrera sedan räknare i början och slutet av intervallet. Detta skiljer förgrundskonkurrens från en återhämtningsprocess som inte kan gå framåt på egen hand.

Om framsteg återupptas när belastningen minskar, välj en lägre underhållsprioritet eller ett tystare schema. Om räknare förblir fasta och samma fel upprepas, tillför ytterligare väntan utan undersökning lite information.

Vanliga frågor

Är 99,9 procent i en timme automatiskt avstannad?

Nej. Slutliga metadatauppdateringar eller en verifieringsfas kan ta tid. Bekräfta om bearbetade block, enhetsskrivningar eller driftstatus fortfarande ändras innan du ingriper.

Ska jag höja ombyggnadens hastighetsgräns?

Endast efter att ha bevisat att diskarna är friska och att förgrundens I/O-policy är flaskhalsen. En högre gräns kan förvärra applikationslatens och lägga mer press på en marginal källa.

När ska jag sluta vänta?

Sluta behandla det som normalt när räknare förblir oförändrade vid upprepade kontroller och loggar visar ett avbrott, återkommande enhetsåterställning, oåterkallelig läsning eller fel vid samma blockintervall.

Den arbetsdefinition av avstannad

En ombyggnad är avstannad när mätbart arbete har upphört och systemet inte kan förklara pausen som policy, belastning eller en ny fas. Använd räknare och felbevis, inte oro eller klocktid.