Impossibile scrivere zero in settori danneggiati / disco rigido che non conta settori riallocati

Ho un disco che sta segnalando che gli attuali settori in sospeso è "45". Ho usato i badblock per identificare i settori e ho provato a scrivere zero con loro con dd .

Da quello che ho capito, quando provo a scrivere i dati direttamente nei settori danneggiati, dovrebbe innescare una riallocazione, riducendo di uno i settori in sospeso attuali e aumentando il conteggio dei settori riallocati.

Tuttavia, su questo disco i valori non elaborati di Reallocated_Sector_Ct e Reallocated_Event_Count sono 0 e dd non riesce con errori I / O quando tento di scrivere zeri nei settori danneggiati. dd funziona bene, tuttavia, quando scrivo in un buon settore.

# dd if=/dev/zero of=/dev/sdb bs=512 count=1 seek=217152
dd: error writing ‘/dev/sdb’: Input/output error

Questo significa che il mio disco, in qualche modo, non ha settori di riserva da utilizzare per la riallocazione? La mia guida è solo in generale una persona terribile? (Il disco non è in realtà il mio, sto aiutando un amico. Potrebbero aver appena ottenuto un disco economico o qualcosa del genere.)

Nel caso sia rilevante, ecco l'output di smartctl -i :

Model Family:     Western Digital Caviar Green (AF)
Device Model:     WDC WD15EARS-00Z5B1
Serial Number:    WD-WMAVU3027748
LU WWN Device Id: 5 0014ee 25998d213
Firmware Version: 80.00A80
User Capacity:    1,500,301,910,016 bytes [1.50 TB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Fri Oct 18 17:47:29 2013 CDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

AGGIORNAMENTO:
ho eseguito shredsul disco, il che ha portato a zero Current_Pending_Sector. Tuttavia, Reallocated_Sector_Ct e Reallocated_Event_Count sono ancora pari a zero e dd è ora in grado di scrivere dati nei settori in cui non era precedentemente in grado. Questo mi porta con diverse altre domande:

Perché le riallocazioni non vengono registrate dal disco? Suppongo che la riallocazione sia avvenuta in quanto ora posso scrivere i dati direttamente nel settore e prima non potevo.
Perché shred ha causato la riallocazione e non il dd? Il fatto che shred scriva dati casuali anziché solo zeri fa la differenza?

— Metanova
fonte

Come sono gli altri valori SMART? È Uncorrectable Sector Countpiù di zero?

— Synetech,

Offline_Uncorrectable, che presumo sia la stessa cosa, ha un valore grezzo di 25.

— MetaNova,

Sì, lo è, e sembra che l'unità sia davvero in cattive condizioni. È possibile verificare i valori in questa tabella , prestando particolare attenzione alle righe rosse (valori critici per la salute). La soluzione migliore è copiare (non spostare) tutto ciò che è prezioso / insostituibile da qualche altra parte, riavviare per dargli un ciclo di accensione e, se funziona ancora, dargli una buona pulizia (preferibilmente con i suoi strumenti dedicati e metterlo da parte come spazio di riserva per dati non importanti come i video scaricati

— Synetech,

Grazie per la risposta. La mia domanda principale dovrebbe probabilmente essere il motivo per cui non è possibile riallocare tali settori. Non dovrebbe semplicemente rilevare i settori danneggiati, evitarli nel vuoto, riallocare e andare avanti? Non sono preoccupato per i dati sul disco poiché sono stati a lungo cancellati. Il mio amico non è desideroso di avere un fermacarte da 1,5 TB se può evitarlo.

— MetaNova,

Sembra la cosa da aspettarsi, ma potrebbe essere che ha una brutta testa. In tal caso, quindi provare a leggere l'unità funzionerebbe fino a quando non si tenta di accedere al piatto che ha una testa difettosa, quindi si otterranno un sacco di errori di lettura perché senza una testa da leggere, l'intero piatto è inaccessibile. Ovviamente afferma che il settore 45 è negativo, forse perché è già stato riassegnato ma SMART non è stato aggiornato. La garanzia è scaduta alcuni mesi fa, ma puoi provare a inviarli via email e forse faranno una sostituzione di cortesia.

— Synetech,

Risposte:

L'unità WD15EARS (e la maggior parte delle altre unità prodotte di recente) utilizza il formato avanzato , il che significa che la dimensione del settore fisico reale di questa unità è di 4 KiB e la tradizionale dimensione del settore a 512 byte viene appena emulata. Per questo motivo, se un singolo settore fisico a 4 KiB si guasta, tutti gli 8 settori corrispondenti a 512 byte emulati diventano illeggibili contemporaneamente.

(L' Sector Size: 512 bytes logical/physicaloutput da smartctlnon è corretto, perché alcune unità WD15EARS riportano dimensioni del settore fisico errate - a quanto pare l'unità ha una versione del firmware che è rotta a tale riguardo.)

Inoltre, quando viene scritto un singolo settore emulato a 512 byte, l'unità Advanced Format deve effettivamente leggere l'intero settore fisico a 4 KiB, modificarne la corrispondente parte a 512 byte, quindi scrivere l'intero settore fisico sul supporto. Se il supporto è buono, questa operazione di lettura-modifica-scrittura provoca solo un rallentamento significativo rispetto a un'unità con settori fisici reali da 512 byte. Tuttavia, se il settore fisico a 4 KiB è danneggiato e non può essere letto, qualsiasi operazione di scrittura che non riscrive completamente il settore fallirà. Per questo motivo, non è possibile forzare la riallocazione del settore su tali unità utilizzando ddcon bs=512 count=1 - è necessario utilizzare almeno bs=512 count=8e assicurarsi che il numero di settore nellaseek= l'opzione è un multiplo di 8. (Ciò presuppone che il jumper “Compatibile con Windows XP” non sia installato, altrimenti deve essere preso in considerazione anche l'offset di allineamento aggiunto da questo jumper.)

Un altro motivo per cui forzare la riallocazione con ddpotrebbe non riuscire è che per impostazione predefinita Linux utilizza una cache nello strato di blocco per accedere ai dispositivi a blocchi, e ciò può causare operazioni di lettura-modifica-scrittura nel software, che potrebbero anche fallire quando si incontra un settore illeggibile. È possibile aggiungere l' oflag=directopzione per bypassare questa cache per il dispositivo specificato da of=...(esiste anche l' iflag=directopzione, che si applica al dispositivo di input).

— Sergey Vlasov
fonte

Grazie, grazie, grazie, è stato molto utile. Ho letto l'etichetta sul disco e dice "formato avanzato". So cosa significa ora ... Hai qualche idea, tuttavia, sull'unità che non segnala alcun settore riallocato?

— MetaNova,

Gli "attuali settori in sospeso" non sono necessariamente settori danneggiati, il disco ha appena avuto un po 'di problemi a leggerlo prima nei suoi controlli inattivi, probabilmente a causa del fatto che non ha scritto lì per molto tempo e che i dati iniziano a svanire (cioè indebolimento del campo magnetico ). La scrittura di nuovi dati in quel settore aggiorna i dati in quel settore con nuovi dati fortemente formati sul disco. Pertanto, se si scrive in un settore in sospeso, il disco assume che ora sia ok. Dovresti provare a rileggere i dati da quei settori per confermare che sono stabili.

— BeowulfNode42,

per quelle persone che non si preoccupano di alcun dato sul disco e non vogliono trovare l'elenco esatto dei settori o fare il conteggio dei settori matematica hanno semplicemente l'intero disco con una dimensione di blocco di un multiplo di 4KiB, come 16MiB. Quindi utilizzare una dimensione del blocco di 4KiB per l'ultima parte del disco che è inferiore alla dimensione del blocco scelta in precedenza.

— BeowulfNode42,

Ho dovuto farlo di recente e ho scoperto che l'esecuzione di shred su tutto il disco ha funzionato molto bene. Mentre shred è inutile per lo scopo previsto tranne che sui dischetti, fa esattamente ciò che è necessario per far sì che l'autoguarigione vada in blocco.

— emil
fonte