Un settore illeggibile in sospeso è quello che ha restituito un errore di lettura e che l'unità ha contrassegnato per la rimappatura alla prima occasione possibile. Tuttavia, non può eseguire la rimappatura fino a quando non si verifica una di queste due cose:
- 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 problema:
- Continua a provare a rileggere il settore finché 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à sta iniziando 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 interessano i dati sull'unità, ti consiglio di metterlo fuori servizio e utilizzare l'eccellente strumento ddrescue per recuperare quanti più dati possibile. Quindi elimina l'unità.
Se il settore in questione contiene dati che non ti interessano o puoi ripristinare da un backup, sovrascriverli è probabilmente la soluzione più rapida e semplice. Puoi quindi visualizzare i conteggi riallocati e in attesa per l'unità per assicurarti che il settore sia stato curato.
Come si fa a sapere a cosa corrisponde il settore nel filesystem? Ho trovato un ottimo articolo su smartmontools sito web, 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), è usare find / -xdev -type f -print0 | xargs -0 ... per leggere ogni file sul sistema. Prendi nota del conteggio in sospeso prima di eseguirlo. Se il settore è all'interno di un file, riceverai un messaggio di errore dallo strumento che hai utilizzato per leggere i file (ad esempio md5sum) che ti mostra il percorso. Puoi quindi focalizzare la tua attenzione sulla rilettura solo 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 solo alcune volte. Se l'errore scompare o non riscontri errori nella lettura di tutti i file, controlla il conteggio in sospeso per vedere se è diminuito. In caso affermativo, il problema è stato risolto leggendo.
Se il file non può essere letto correttamente dopo più tentativi (ad esempio 20), è necessario sovrascrivere il file, o il blocco all'interno del file, per consentire all'unità di riallocare il settore. Puoi usare ddrescue sul file (piuttosto che sulla partizione) per sovrascrivere solo un settore, copiandolo in un file temporaneo e poi copiandolo di nuovo. Si noti che rimuovere semplicemente il file a questo punto è una cattiva idea, perché il settore danneggiato andrà nell'elenco libero dove sarà più difficile da trovare. Anche sovrascriverlo completamente è un male, perché ancora una volta i settori andranno nell'elenco libero. Devi riscrivere i blocchi esistenti. Il notrunc opzione di dd è un modo per farlo.
Se non si riscontrano errori e il conteggio in sospeso non è diminuito, il settore deve trovarsi nella freelist o in parte dell'infrastruttura del filesystem (ad esempio una tabella inode). Puoi provare a riempire tutto lo spazio libero con cat /dev/zero >tempfile e quindi controllare il conteggio in sospeso. Se va giù, il problema era nella lista libera e ora è andato via.
Se il settore è nell'infrastruttura, hai un problema più serio e probabilmente incontrerai errori semplicemente camminando nell'albero delle directory. In questa situazione, penso che l'unica soluzione sensata sia riformattare l'unità, eventualmente utilizzando ddrescue per recuperare i dati se necessario.
Tieni d'occhio il disco molto da vicino. La riallocazione del settore è un ottimo canarino nella miniera di carbone, che potenzialmente ti avvisa in anticipo di un disco che sta fallendo. Agendo tempestivamente è possibile prevenire una successiva frana catastrofica e molto dolorosa. Non sto suggerendo che alcune riallocazioni di settore indichino che dovresti scartare l'unità. Tutte le unità moderne devono eseguire una riallocazione. Tuttavia, se l'unità non è molto vecchia (<1 anno) o ricevi frequenti nuove riallocazioni (> 1/mese), ti consiglio 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 con un dd del disco grezzo o leggendo ogni file usando find . Quasi tutti i problemi del disco che ho riscontrato negli ultimi anni sono emersi prima in file usati raramente o su macchine che non vengono usate molto. Ciò ha senso anche dal punto di vista euristico, in quanto se un settore viene riletto frequentemente, l'unità ha la possibilità di riallocarlo quando rileva per la prima volta un problema minore con quel settore piuttosto che attendere che il settore sia 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 conducendo uno dei test SMART.
Mi piacerebbe sperimentare l'idea di un cron job notturno o settimanale che legga l'intero disco. Attualmente sto usando un "RAID dei poveri" in cui ho un secondo disco rigido nella macchina e ogni notte eseguo il backup del disco principale su di esso. In un certo senso, questo è in realtà migliore del mirroring RAID, perché se sbaglio 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 correggere i problemi del disco non appena emergono. Il mio attuale script di backup usa rsync per evitare di copiare dati che non sono cambiati, ma vista la necessità di rileggere tutti i settori forse sarebbe meglio copiare tutto, oppure avere uno script separato che legga l'intero disco raw ogni settimana.