Un settore illeggibile in sospeso è quello che ha restituito un errore di lettura e che l'unità ha contrassegnato per il remapping alla prima occasione possibile. Tuttavia, non è possibile eseguire il remapping fino a quando non si verifica una delle due cose seguenti:
- Il settore viene riletto con successo
- Il settore viene riscritto
Fino ad allora, il settore rimane in sospeso. Quindi hai due modi corrispondenti per affrontare questo:
- Continua a provare a rileggere il settore fino a quando non ci riesci
- Sovrascrivi quel settore con nuovi dati
Ovviamente, (1) non è distruttivo, quindi dovresti probabilmente provarlo prima, anche se tieni presente che se l'unità inizia a guastarsi in modo serio, è probabile che la lettura continua da un'area danneggiata lo faccia fallire molto più rapidamente . Se hai molti settori in sospeso e altri errori e ti preoccupi dei dati sul disco, ti consiglio di metterli fuori servizio e utilizzare l'eccellente strumento ddrescue per recuperare quanti più dati possibili. Quindi scartare l'unità.
Se il settore in questione contiene dati che non ti interessano o che è possibile ripristinare da un backup, la sovrascrittura è probabilmente la soluzione più rapida e semplice. È quindi possibile visualizzare i conteggi riallocati e in sospeso per l'unità per assicurarsi che il settore sia stato curato.
Come scopri a cosa corrisponde il settore nel filesystem? Ho trovato un eccellente articolo sul sito web smartmontools , qui , anche se è abbastanza tecnico ed è specifico per i file system ext2 / 3/4 e reiser.
Un approccio più semplice, che ho usato su una delle mie unità (Mac), è di usare find / -xdev -type f -print0 | xargs -0 ...per leggere tutti i file sul sistema. Prendi nota del conteggio in sospeso prima di eseguire questo. Se il settore si trova all'interno di un file, verrà visualizzato un messaggio di errore dallo strumento utilizzato per leggere i file (ad es. Md5sum) che mostra il percorso verso di esso. Puoi quindi focalizzare le tue attenzioni sulla rilettura di questo file fino a quando non viene letto correttamente. Spesso questo risolverà il problema, se si tratta di un file usato di rado che doveva essere riletto alcune volte. Se l'errore scompare o non si verificano errori nella lettura di tutti i file, controllare il conteggio in sospeso per vedere se è diminuito. In tal caso, il problema è stato risolto leggendo.
Se il file non può essere letto correttamente dopo più tentativi (ad es. 20), è necessario sovrascrivere il file o il blocco all'interno del file per consentire all'unità di riallocare il settore. È possibile utilizzare ddrescue sul file (anziché sulla partizione) per sovrascrivere solo un settore, copiandolo in un file temporaneo e quindi copiandolo di nuovo. Si noti che rimuovere il file a questo punto è una cattiva idea, perché il settore danneggiato andrà nell'elenco gratuito dove sarà più difficile da trovare. Anche la sovrascrittura completa è negativa, perché i settori torneranno nell'elenco gratuito. Devi riscrivere i blocchi esistenti. L' notruncopzione di ddè un modo per farlo.
Se non si riscontrano errori e il conteggio in sospeso non è diminuito, il settore deve essere nella lista dei freelist o in parte dell'infrastruttura del filesystem (ad es. Una tabella di inode). Puoi provare a riempire tutto lo spazio libero con cat /dev/zero >tempfile, quindi controllare il conteggio in sospeso. Se il problema persiste, il problema era nell'elenco gratuito e ora è scomparso.
Se il settore si trova nell'infrastruttura, hai un problema più serio e probabilmente incontrerai degli errori semplicemente camminando sull'albero delle directory. In questa situazione, penso che l'unica soluzione sensata sia quella di riformattare l'unità, usando facoltativamente ddrescue per recuperare i dati se necessario.
Tieni d'occhio il disco. La riallocazione settoriale è un ottimo canarino nella miniera di carbone , potenzialmente in grado di avvisare tempestivamente di un guasto. Agendo tempestivamente puoi prevenire una frana successiva catastrofica e molto dolorosa. Non sto suggerendo che alcune riallocazioni settoriali siano un'indicazione che è necessario eliminare l'unità. Tutte le unità moderne devono essere riallocate. Tuttavia, se l'unità non è molto vecchia (<1 anno) o si ottengono nuove riallocazioni frequenti (> 1 / mese), si consiglia di sostituirla al più presto.
Non ho prove empiriche per dimostrarlo, ma la mia esperienza suggerisce che i problemi del disco possono essere ridotti leggendo l'intero disco una volta ogni tanto, o da uno dddei dischi non elaborati o leggendo tutti i file che utilizzano find. Quasi tutti i problemi del disco che ho riscontrato negli ultimi anni sono emersi per primi in file usati raramente o su macchine che non sono molto utilizzate. Ciò ha senso anche in modo euristico, in quanto se un settore viene riletto frequentemente, l'unità ha la possibilità di riallocare quando rileva per la prima volta un problema minore con quel settore piuttosto che aspettare fino a quando il settore è completamente illeggibile. L'unità non è in grado di fare nulla con un settore a meno che l'host non vi acceda in qualche modo, leggendolo o scrivendolo o eseguendo uno dei test SMART.
Mi piacerebbe sperimentare l'idea di un cron job notturno o settimanale che legge l'intero disco. Attualmente sto usando un "RAID povero" in cui ho un secondo disco rigido nella macchina e ogni notte eseguo il backup del disco principale. In un certo senso, questo è in realtà meglio del mirroring RAID, perché se eseguo il goof ed elimino un file per errore, posso ottenere immediatamente la versione di ieri dal disco di backup. D'altra parte, credo che un controller RAID hardware faccia un ottimo lavoro in background per monitorare, segnalare e risolvere i problemi del disco non appena emergono. Il mio attuale script di backup usa rsyncper evitare la copia di dati che non sono cambiati, ma in considerazione della necessità di rileggere tutti i settori, forse sarebbe meglio copiare tutto o avere uno script separato che legge l'intero disco grezzo ogni settimana.