Un settore danneggiato indica un disco guasto?

Il mio sistema Ubuntu 13.10 ha funzionato molto male nell'ultimo giorno circa. Osservando i log del kernel, sembra che il disco SATA da 3 TB <1 anno precedente abbia problemi con un determinato settore:

Nov  4 20:54:04 mediaserver kernel: [10893.039180] ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Nov  4 20:54:04 mediaserver kernel: [10893.039187] ata4.01: BMDMA stat 0x65
Nov  4 20:54:04 mediaserver kernel: [10893.039193] ata4.01: failed command: READ DMA EXT
Nov  4 20:54:04 mediaserver kernel: [10893.039202] ata4.01: cmd 25/00:08:f8:3f:83/00:00:af:00:00/f0 tag 0 dma 4096 in
Nov  4 20:54:04 mediaserver kernel: [10893.039202]          res 51/40:00:f8:3f:83/40:00:af:00:00/10 Emask 0x9 (media error)
Nov  4 20:54:04 mediaserver kernel: [10893.039207] ata4.01: status: { DRDY ERR }
Nov  4 20:54:04 mediaserver kernel: [10893.039211] ata4.01: error: { UNC }
Nov  4 20:54:04 mediaserver kernel: [10893.148527] ata4.00: configured for UDMA/133
Nov  4 20:54:04 mediaserver kernel: [10893.180322] ata4.01: configured for UDMA/133
Nov  4 20:54:04 mediaserver kernel: [10893.180345] sd 3:0:1:0: [sdc] Unhandled sense code
Nov  4 20:54:04 mediaserver kernel: [10893.180349] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180353] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov  4 20:54:04 mediaserver kernel: [10893.180356] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180359] Sense Key : Medium Error [current] [descriptor]
Nov  4 20:54:04 mediaserver kernel: [10893.180371] Descriptor sense data with sense descriptors (in hex):
Nov  4 20:54:04 mediaserver kernel: [10893.180373]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Nov  4 20:54:04 mediaserver kernel: [10893.180384]         af 83 3f f8
Nov  4 20:54:04 mediaserver kernel: [10893.180389] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180393] Add. Sense: Unrecovered read error - auto reallocate failed
Nov  4 20:54:04 mediaserver kernel: [10893.180396] sd 3:0:1:0: [sdc] CDB:
Nov  4 20:54:04 mediaserver kernel: [10893.180398] Read(16): 88 00 00 00 00 00 af 83 3f f8 00 00 00 08 00 00
Nov  4 20:54:04 mediaserver kernel: [10893.180412] end_request: I/O error, dev sdc, sector 2944614392
Nov  4 20:54:04 mediaserver kernel: [10893.180431] ata4: EH complete

Il kern.logfile è di circa 33 MB, per lo più pieno dell'errore precedente ripetuto e il settore non sembra essere diverso nei messaggi ripetuti.

Attualmente sto eseguendo il seguente comando sul disco ora non montato per testare e tentare di risolvere eventuali problemi che il disco potrebbe avere. Sono circa 12 ore e mi aspetto che ci vorranno altre 24/48 ore poiché il disco è così grande:

e2fsck -c -c -p -v /dev/sdc1

La mia domanda è: questa unità non funziona o sto esaminando un problema comune qui? Mi chiedo se per me sia utile riparare o ignorare settori danneggiati e se dovrei sostituire il disco in garanzia mentre è ancora coperto. La mia conoscenza del comando sopra è in qualche modo carente, quindi sono scettico sul fatto che possa aiutare o no.

Aggiornamento rapido!

e2fsck alla fine è terminato dopo 2 giorni con un sacco di "blocchi multipli rivendicati nell'inode". Il tentativo di montare il filesystem ha provocato un errore, costringendolo a tornare in sola lettura:

Nov 11 08:29:05 mediaserver kernel: [211822.287758] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended
Nov 11 08:29:05 mediaserver kernel: [211822.301699] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: errors=remount-ro

Prova a leggere il settore manualmente:

sudo dd count=1 if=/dev/sdc of=/dev/null skip=2944614392
dd: reading ‘/dev/sdc’: Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 5.73077 s, 0.0 kB/s

Cercando di scrivergli:

sudo dd count=1 if=/dev/zero of=/dev/sdc seek=2944614392
dd: writing to ‘/dev/sdc’: Input/output error
1+0 records in
0+0 records out
0 bytes (0 B) copied, 2.87869 s, 0.0 kB/s

In entrambi i casi, lo Reallocated_Sector_Ct0 è rimasto.

L'unità entra in uno stato di sospensione abbastanza spesso. Ora sto pensando che questo potrebbe essere un problema di filesystem? Non sono al 100%.

I settori danneggiati sono sempre un'indicazione di un HDD difettoso, infatti nel momento in cui vedi un errore I / O come questo, probabilmente hai già perso / danneggiato alcuni dati. Effettua un backup se non ne hai già uno, esegui un test automatico smartctl -t long /dev/diske controlla i dati SMART smartctl -a /dev/disk. Ottieni una sostituzione se puoi.

I settori danneggiati non possono essere riparati, sostituiti solo dai settori di riserva, il che danneggia le prestazioni dell'HDD, in quanto richiedono ulteriori ricerche nei settori di riserva ogni volta che vi si accede. Contrassegnare settori come dannosi sul livello del filesystem aiuta, dato che non saranno mai accessibili allora; tuttavia è difficile determinare quali settori sono già stati riallocati dal disco, quindi è probabile che il filesystem non sappia evitare la regione interessata.

Per creare il drive per riallocare i settori, di solito è necessario scrivere qualcosa in essi. Tuttavia, dd( D isk D estroyer) non sempre funziona ed è molto pericoloso: se confondi le opzioni skipe seek, puoi facilmente spararti nel piede skipeseguendo il ping dei Nprimi blocchi di /dev/zeroe scrivendo un blocco da quel "offset" sopra il settore 0 del tuo disco rigido .

Se sai davvero che vuoi forzare la sovrascrittura del settore con zero, dovresti usare hdparm:

% sudo hdparm --read-sector 833192656 /dev/sda
/dev/sda:
reading sector 833192656: FAILED: Input/output error

Sì, anche il settore 833192656 stava fallendo nei test intelligenti. Per scrivere zero su di esso, utilizzare --write-sector:

% sudo hdparm --write-sector 833192656 /dev/sda
/dev/sda:
Use of --write-sector is VERY DANGEROUS.
You are trying to deliberately overwrite a low-level sector on the media.
This is a BAD idea, and can easily result in total data loss.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

A titolo di salvaguardia, in hdparmrealtà non scrive nulla a meno che non passi il --yes-i-know-what-i-am-doingpassaggio a hdparm:

% sudo hdparm --yes-i-know-what-i-am-doing --write-sector 833192656 /dev/sda
/dev/sda:
re-writing sector 833192656: succeeded
% sudo hdparm --read-sector 833192656 /dev/sda                              

/dev/sda:
reading sector 833192656: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
[      ... more zeroes here...        ]
0000 0000 0000 0000 0000 0000 0000 0000

%

No, i settori danneggiati non sono sempre un'indicazione di un'unità guasta . A volte se una scrittura è in corso al momento di un'interruzione dell'alimentazione, i dati nel settore verranno danneggiati, causando un errore quando si tenta di leggerlo. Il tentativo di scrivere nuovi dati nel settore potrebbe funzionare bene poiché non c'è nulla di fisicamente sbagliato.

È possibile eseguire badblocks -nsull'unità per leggere e riscrivere ogni settore o, nel tuo caso, poiché si conosce già il numero del settore in questione, è possibile utilizzare ddper scrivere zero su di esso. È possibile controllare le statistiche SMART con smartctl -a. Dovresti vedere il conteggio riallocato in sospeso che indica quanti settori non sono riusciti a leggere e, dopo aver tentato di scrivere il settore, questo conteggio diminuirà. Il conteggio del settore riallocato potrebbe aumentare, nel qual caso era fisicamente difettoso ed è stato rimappato nel pool di riserva, e questo potrebbe essere un segno che l'unità sta per uscire. In caso contrario, allora è stato solo confuso e dovrebbe andare bene ora.

Prova a leggere prima il settore:

dd count=1 if=/dev/sda of=/dev/null skip=nnnn

Se fallisce, allora hai il numero giusto, quindi puoi azzerarlo con:

dd count=1 if=/dev/zero of=/dev/sda seek=nnnn

Ricontrolla di aver digitato il comando esattamente prima di premere invio.