Soluzione 1:
Scrivevo il firmware del disco per WD e una volta ho scritto il firmware che riassegnava i blocchi danneggiati.
Innanzitutto, la maggior parte dei blocchi danneggiati viene rilevata durante le letture, non le scritture. Le scritture vengono eseguite alla cieca, il che significa che i dati vengono scritti senza essere controllati. Pertanto, durante una scrittura, se il supporto è cattivo, non lo saprai fino a quando l'host non leggerà quel settore. C'è una piccola parte del settore (l'intestazione del settore) che viene letta durante le scritture per individuare il settore corretto, in modo che se si verifica un errore nella lettura dell'intestazione del settore, l'unità riassegna il settore e lo scrive con i dati ricevuti dal comando di scrittura. Ma la stragrande maggioranza dei blocchi danneggiati viene rilevata durante le letture e solo perché una scrittura riesce in un settore non significa che il supporto sia buono o che il settore sia stato riassegnato.
Ora sulla riassegnazione dei blocchi errati (chiamata anche riallocazione). Sì, normalmente l'unità tenterà di riassegnare un settore se l'errore è abbastanza grave (ad esempio, l'errore ECC è abbastanza grave) ma l'unità potrebbe comunque recuperare i dati dopo la correzione ECC. Di solito questo viene fatto automaticamente. L'unica eccezione è che l'host potrebbe aver detto in precedenza all'unità di non eseguire riallocazioni automatiche, ma ciò accade 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 eseguita 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 scrivesse solo un mucchio di zeri, diciamo, e poi il settore venisse letto di nuovo, restituirebbe 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 sul fatto che l'host tenga traccia degli errori per una serie di motivi (ad esempio, cosa succede se l'unità è stata spostata su un nuovo host?), quindi la migliore linea d'azione è non fare nulla quando i dati non possono t essere recuperato.
Le unità moderne, tuttavia, salveranno la posizione del settore danneggiato quando non può essere riallocato. Il numero di settori danneggiati in attesa di riallocazione può essere trovato nei dati SMART. Quello che succede è che se viene eseguita una scrittura su uno dei settori danneggiati in attesa di riallocazione, la riallocazione viene eseguita perché l'unità ora ha dati validi da scrivere dopo la riallocazione. Quindi, quando le persone dicono che scrivere in un settore danneggiato lo riallocherà, questa è davvero solo metà della storia. L'unità deve essere letta per prima in modo che possa rilevare tutti i settori danneggiati che non possono essere riallocati automaticamente. Quindi puoi scrivere un'intera unità e i dati SMART diranno che non ci sono settori danneggiati in attesa di riallocazione, ma non hai necessariamente cancellato l'unità da tutti i settori danneggiati. Quindi, se vuoi davvero cancellare un'unità da tutti i settori danneggiati, la cosa migliore è leggere prima l'intera unità, quindi scrivere l'intera unità (ovviamente, questo distruggerà tutti i dati precedenti sull'unità).
Esistono altri modi per gestire i blocchi danneggiati che non possono essere riallocati. Se l'unità fa parte di una configurazione RAID ridondante (ovvero, tutt'altro che 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 nel blocco, ma il suo utilizzo è piuttosto di basso livello.
Soluzione 2:
Potresti provare hdparm --write-sector <LBA> /dev/ice .
Non conosco nessun altro modo per farlo:devi convertire manualmente l'LBA in blocchi di filesystem (come hai già scoperto)
Soluzione 3:
Penso che tutto ciò che devi fare sia:
e2fsck -c /dev/hda1
supponendo che /dev/hda1 sia la partizione (non montata). Oppure:
e2fsck -c -c /dev/hda1
per eseguire un test di lettura-scrittura (più lento) non distruttivo. Dovrà ancora essere smontato. Tuttavia, non credo che questo ti fornirà dettagli su eventuali dati persi.
Soluzione 4:
Michael ha ragione e nella maggior parte dei casi direi basta sostituire l'unità che sono economici. Tuttavia, se non disponi di backup e non riesci a ottenere dati importanti dall'unità, o desideri semplicemente tentare di riparare l'unità, potresti provare a utilizzare spinrite, al livello più alto.
Ho avuto un'unità per laptop che ha iniziato a fare dei rumori alcuni anni fa. Badblocks ha mostrato che l'unità aveva circa 118 blocchi danneggiati visibili all'utente finale. Dato che avevo già una copia di SpinRite, ho deciso di provarlo prima di acquistare una nuova unità. Dopo aver eseguito spinrite sull'unità, i blocchi danneggiati hanno mostrato 0 blocchi danneggiati e i rumori si sono interrotti. L'unità ha funzionato per oltre due anni da allora.