Quanto tempo dovresti aspettare prima di considerare bloccata la ricostruzione di un RAID?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How Long Should You Wait Before Calling a RAID Rebuild Stalled? - Zima Store Online

Considera una ricostruzione RAID bloccata solo quando il conteggio dei blocchi processati smette di aumentare dopo controlli ripetuti e i log non mostrano pause intenzionali, limitazioni di priorità, fasi in coda o tentativi di recupero. Il tempo trascorso da solo non è sufficiente.

I grandi array possono passare ore in una regione lenta, cambiare velocità bruscamente sotto carico applicativo o mettere in pausa tra ricostruzione e verifica. Accerta il movimento con contatori e log prima di intervenire, perché fermare o riassemblare un array può creare più rischi che aspettare.

Usa la Variazione di Progresso, non una Singola Percentuale

Registra il conteggio esatto dei blocchi processati, la percentuale, la velocità e il tempo stimato di completamento a intervalli fissi. Una ricostruzione è in corso quando il conteggio dei blocchi aumenta, anche se la percentuale arrotondata rimane invariata. Su array multi-terabyte, un decimo di percento visualizzato può rappresentare una grande quantità di lavoro.

Controlla il controller o il sistema operativo dalla stessa interfaccia ogni volta. Cruscotti diversi possono memorizzare lo stato nella cache o riportare fasi diverse. Una barra di progresso che sembra bloccata mentre i contatori di blocchi avanzano è un problema di monitoraggio, non una ricostruzione bloccata.

Stima una Baseline Locale invece di un Timeout Universale

Non esiste un numero unico di ore sicuro. Il tempo di ricostruzione dipende dalla capacità utilizzata, dalla configurazione RAID, dalla velocità del disco, dagli errori, dalla politica del controller, dal carico di fondo e dal fatto che l'implementazione copi tutti i blocchi o solo le regioni allocate.

Usa la prima ora stabile per stimare un intervallo approssimativo, poi confronta gli intervalli successivi. Una velocità di risincronizzazione mdadm molto lenta può derivare dal carico di lavoro, dall'allineamento, dal comportamento del collegamento o da un disco in difficoltà; la diagnosi corretta richiede più di un semplice aumento del limite di velocità.

Cerca una Pausa Intenzionale o una Nuova Fase

Alcuni sistemi limitano il recupero per proteggere l'I/O in primo piano, mettono in pausa le scansioni durante il resilver, attendono l'assegnazione di una riserva o passano dalla ricostruzione all'inizializzazione della parità o alla verifica della coerenza. L'etichetta può rimanere "ricostruzione" mentre il compito attivo cambia.

Rivedi la manutenzione programmata, le impostazioni di alimentazione, i limiti di temperatura, la priorità di ricostruzione e il traffico applicativo. Se la velocità aumenta quando il carico in primo piano diminuisce, l'array è vincolato dalle risorse e non bloccato.

Errori di lettura ripetuti creano un vero stallo

Un drive sorgente può impiegare molto tempo a riprovare un settore debole, causando un crollo del throughput vicino allo stesso intervallo di blocchi. Se il controller segnala infine una lettura irrecuperabile, la ricostruzione può abortire perché la ridondanza non può ricostruire quella regione.

Un ricostruzione interrotta da errori di lettura dimostra perché l'ultimo blocco riuscito e l'errore del kernel subito dopo sono importanti. Non riavviare ripetutamente un recupero che fallisce allo stesso indirizzo senza proteggere i dati ed esaminare il membro sorgente.

Una velocità zero con attività di log può indicare tentativi di ripetizione

Una velocità visualizzata pari a zero può verificarsi durante i tentativi di comando, i reset del dispositivo, il recupero errori, gli aggiornamenti dei metadati o una pausa temporanea. Osserva il tempo di occupazione del disco, la profondità della coda, gli eventi del controller e i messaggi del kernel. Reset o timeout ripetuti non indicano un progresso sano.

Un recupero che si interrompe ripetutamente mostra anche che non ogni arresto ha un evidente errore SMART. Cattura il punto esatto e tutti i log invece di presumere che un nuovo disco o una velocità più alta risolvano il problema.

Usa una Tabella di Decisione per Stallo Pratico

Osservazione su due o più intervalli	Interpretazione	Azione
Aumento dei blocchi elaborati	Lento ma in movimento	Continua il monitoraggio
Percentuale invariata, aumento dei blocchi	Visualizza arrotondamento	Attendi
Blocchi invariati, il compito risulta in pausa	Sospensione intenzionale	Trova la pausa o la ragione della politica
Blocchi invariati, tentativi/ripristini ripetuti	Problema hardware o di percorso	Riduci le scritture; ispeziona la sorgente e la connessione
Si ferma allo stesso blocco dopo il riavvio	Regione illeggibile persistente	Proteggi i dati; interrompi i tentativi ciechi
99,9% con fase di follow-up attiva	Finalizzazione o lavoro sui metadati	Verifica l'etichetta dell'operazione e i log

Richiedi prove da almeno due segnali indipendenti prima di dichiarare la ricostruzione bloccata: nessun movimento dei contatori più un errore, stato abortito o punto di arresto identico persistente.

Cosa Fare Prima di Riavviare Qualcosa

Salva i dettagli dell'array, i numeri seriali dei membri, i contatori dei blocchi processati e il registro completo degli eventi.
Riduci l'I/O applicativo non essenziale e conferma che i dischi di destinazione e sorgente rimangano rilevati.
Controlla gli indicatori SMART del supporto e i contatori di reset del collegamento o CRC su ogni sorgente attiva.
Conferma che non ci sia uno stato in pausa, limite di temperatura, politica di priorità o fase di verifica in coda.
Passa a backup, imaging o recupero quando lo stesso intervallo illeggibile blocca i tentativi ripetuti.

Non usare comandi stop, assemble, force-online o metadata-clear finché non si conoscono lo stato dell'array e l'implementazione esatta.

Confronta il Progresso Durante un Intervallo di Quiete

Un test utile di blocco necessita di una finestra di osservazione controllata. Metti in pausa grandi trasferimenti e lavori programmati, quindi registra i contatori all'inizio e alla fine dell'intervallo. Questo separa la contesa in primo piano da un processo di recupero che non può avanzare da solo.

Se il progresso riprende quando il carico diminuisce, scegli una priorità di manutenzione più bassa o un programma più tranquillo. Se i contatori rimangono fissi e lo stesso errore si ripete, attendere ulteriormente senza indagine aggiunge poche informazioni.

FAQ

Il 99,9 percento per un'ora è automaticamente bloccato?

No. Gli aggiornamenti finali dei metadati o una fase di verifica possono richiedere tempo. Conferma se i blocchi processati, le scritture del dispositivo o lo stato dell'operazione stanno ancora cambiando prima di intervenire.

Dovrei aumentare il limite di velocità della ricostruzione?

Solo dopo aver dimostrato che i dischi sono sani e che la politica I/O in primo piano è il collo di bottiglia. Un limite più alto può peggiorare la latenza dell'applicazione e aumentare la pressione su un disco sorgente marginale.

Quando dovrei smettere di aspettare?

Smetti di considerarlo normale quando i contatori rimangono invariati dopo controlli ripetuti e i log mostrano un aborto, un reset ricorrente del dispositivo, una lettura irrecuperabile o un errore nello stesso intervallo di blocchi.

La Definizione Operativa di Blocco

Una ricostruzione si blocca quando il lavoro misurabile si ferma e il sistema non può spiegare la pausa come politica, carico o una nuova fase. Usa contatori e prove di errore, non ansia o tempo di orologio.