Come posso facilmente riparare un singolo blocco illeggibile su un disco Linux?

Il mio sistema Linux ha iniziato a generare errori SMART nel syslog. L'ho rintracciato e credo che il problema sia un singolo blocco sul disco. Come posso fare in modo che il disco possa riallocare facilmente quel blocco? Mi piacerebbe sapere quale file è stato distrutto nel processo. (Sono consapevole che se un blocco si guasta su un disco è probabile che ne seguano altri; ho un buon backup in corso e voglio solo provare a far funzionare questo disco.)

La ricerca sul Web porta al Bad block HOWTO , che descrive un processo manuale su un disco non montato. Sembra complicato e soggetto a errori. Esiste uno strumento per automatizzare questo processo in Linux? La mia unica altra opzione è lo strumento diagnostico del produttore , ma presumo che bloccherà il blocco difettoso senza riferire su ciò che è stato distrutto. Nel peggiore dei casi, potrebbero essere metadati del filesystem.

Il disco in questione è la partizione di sistema primaria. Utilizzo di ext3fs e LVM. Ecco il registro degli errori di syslog e il bit rilevante di smartctl.

smartd[5226]: Device: /dev/hda, 1 Currently unreadable (pending) sectors

Error 1 occurred at disk power-on lifetime: 17449 hours (727 days + 1 hours)
... Error: UNC at LBA = 0x00d39eee = 13868782

C'è un dump smartctl completo su pastebin .

Potresti provare hdparm --write-sector <LBA> /dev/ice.

Non conosco altri modi per farlo - devi convertire manualmente l'LBA in blocchi di filesystem (come hai già trovato)

Scrivevo il firmware del disco per WD e una volta scrissi il firmware che riassegnava i blocchi danneggiati.

Innanzitutto, la maggior parte dei blocchi danneggiati viene rilevata nelle letture, non nelle scritture. Le scritture vengono eseguite alla cieca, il che significa che i dati vengono scritti senza essere controllati. Quindi su una scrittura se il supporto è male, non lo saprai fino a quando l'host non farà una lettura in quel settore. C'è una piccola parte del settore (l'intestazione del settore) che viene letta nelle scritture per individuare il settore corretto, in modo che se si verifica un errore nella lettura dell'intestazione del settore, l'unità riassegnerà il settore e lo scriverà con i dati ricevuti dal comando di scrittura. Ma la stragrande maggioranza dei blocchi danneggiati viene rilevata nelle letture e solo perché una scrittura ha successo in un settore non significa che i media siano buoni o che il settore sia stato riassegnato.

Ora sulla riassegnazione dei blocchi danneggiati (chiamata anche riallocazione). Sì, normalmente l'unità tenterà di riassegnare un settore se l'errore è abbastanza grave (ovvero, l'errore ECC è abbastanza grave) ma l'unità potrebbe ancora recuperare i dati dopo la correzione ECC. Di solito questo viene fatto automaticamente. L'unica eccezione è che l'host avrebbe potuto in precedenza dire all'unità di non effettuare riallocazioni automatiche, ma ciò avviene raramente.

Quindi cosa succede se l'unità esegue una lettura e non riesce a recuperare i dati? Niente. L'errore viene segnalato all'host, ma non viene effettuata alcuna riassegnazione. Il problema è che l'unità potrebbe riassegnare il settore, ma non ha la minima idea di quali dati scrivere nel settore appena riassegnato. Se avesse appena scritto un mucchio di zeri, diciamo, e poi il settore fosse stato letto di nuovo, avrebbe restituito tutti gli zeri senza alcuna indicazione che i dati non fossero validi. Questa è essenzialmente la stessa cosa della corruzione dei dati. L'unità non può contare sull'host che tiene traccia degli errori per una serie di motivi (ad esempio, cosa succede se l'unità è stata spostata su un nuovo host?), Quindi il miglior modo di agire è di non fare nulla quando i dati possono " essere recuperato.

Le unità moderne, tuttavia, salveranno la posizione del settore danneggiato quando non può essere riallocata. Il numero di settori danneggiati in attesa di riallocazione è disponibile nei dati SMART. Ciò che accade è se una scrittura viene eseguita in uno dei settori danneggiati in attesa di riallocazione, la riallocazione viene eseguita perché l'unità ora ha dati validi per scrivergli dopo la riallocazione. Quindi, quando la gente dice che scrivere in un brutto settore lo riallocerà, questa è solo metà della storia. L'unità deve essere letta per prima in modo che l'unità possa scoprire tutti i settori danneggiati che non possono essere riallocati automaticamente. In questo modo è possibile scrivere un'intera unità e i dati SMART diranno che non ci sono settori danneggiati in attesa di riallocazione, ma non è stata necessariamente cancellata l'unità di tutti i settori danneggiati. Quindi, se vuoi davvero cancellare un'unità di tutti i settori danneggiati,

Esistono altri modi per gestire blocchi danneggiati che non possono essere riallocati. Se l'unità fa parte di una configurazione RAID ridondante (ovvero, tranne RAID 0), il software RAID dovrebbe recuperare automaticamente i dati per un settore danneggiato dalle altre unità e scriverli nel settore riallocato. I dischi SCSI hanno un comando esplicito di riassegnazione dei blocchi che l'host può utilizzare per forzare la riassegnazione anche quando non ci sono dati validi da scrivere sul blocco, ma il suo utilizzo è piuttosto basso.

Penso che tutto ciò che devi fare è:

e2fsck -c /dev/hda1

assumendo / dev / hda1 è la partizione (non montata). O:

e2fsck -c -c /dev/hda1

per eseguire un test di lettura / scrittura (più lento) non distruttivo. Dovrà comunque essere smontato. Non credo che questo ti fornirà dettagli su eventuali dati persi.

Michael lo ha corretto e nella maggior parte dei casi direi che è sufficiente sostituire l'unità che costa poco. Tuttavia, se non si dispone di backup e non è possibile ottenere dati importanti dall'unità o si desidera semplicemente tentare di riparare l'unità, è possibile provare a utilizzare spinrite al massimo livello.

Avevo un drive per laptop che ha iniziato a fare qualche rumore qualche anno fa. Badblocks ha mostrato che l'unità aveva 118 blocchi o così male visibili all'utente finale. Dato che avevo già una copia di SpinRite, ho deciso di provarlo prima di acquistare un nuovo disco. Dopo aver eseguito spinrite sull'unità, i badblock hanno mostrato 0 blocchi danneggiati e i rumori si sono fermati. Da allora il disco funzionava da oltre due anni.

Se si dispone di backup e si sa che si tratta di un errore logico e non fisico, il modo migliore per farlo è quello di azzerare il disco.

Vorrei usare MHDD è abbastanza facile da usare e finché ricordi di impostare il tuo HDD in Bios sull'emulazione IDE e poi di nuovo su AHCI quando il tuo lavoro è finito non hai nulla di cui preoccuparti.

Una volta avviato su MHDD, seleziona il tipo di unità nel comando ERASE e conferma la tua scelta.

Prendi te stesso, questo potrebbe richiedere del tempo.

Dopo che l'azionamento è stato azzerato, eseguire scan (f4) con Remap impostato su ON (l'impostazione predefinita è disattivata). Se ci sono ancora problemi con l'unità (ciò significherebbe che c'è un danno fisico sul piatto e l'unità è su una pendenza verso il basso stedy) questa opzione li "risolverà" mappando l'area danneggiata su parti sane dell'unità.

Se non ci sono errori UNC, allora congratulazioni con te e il tuo disco possono ancora essere amici per gli anni a venire.

Se il disco non funziona, sostituirlo. Non vale il rischio che cada di più.