¿Un sector defectuoso indica un disco defectuoso?

Mi sistema Ubuntu 13.10 ha estado funcionando muy mal durante el último día más o menos. Al observar los registros del kernel, parece que el disco SATA de 3 TB de <1 año de antigüedad tiene problemas con un sector en particular:

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

El kern.logarchivo tiene alrededor de 33 MB en su mayoría lleno del error anterior repetido y el sector no parece ser diferente en los mensajes repetidos.

Actualmente estoy ejecutando el siguiente comando en el disco ahora desmontado para probar e intentar solucionar cualquier problema que pueda tener el disco. Tengo alrededor de 12 horas y espero que tome otras 24/48 horas ya que el disco es tan grande:

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

Mi pregunta es: ¿está fallando esta unidad o estoy viendo un problema común aquí? Me pregunto si tiene algún sentido reparar o ignorar los sectores defectuosos y si debería reemplazar el disco en garantía mientras todavía está cubierto. Me falta algo de conocimiento del comando anterior, por lo que soy escéptico sobre si ayudará o no.

¡Actualización rápida!

e2fsck finalmente terminó después de 2 días con muchos 'bloques reclamados múltiples en inodo'. Intentar montar el sistema de archivos resultó en un error, forzándolo a volver a solo lectura:

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

Intentando leer el sector 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

Intentando escribirle:

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

En ambos casos, el Reallocated_Sector_Ct0 permaneció.

La unidad entra en estado de suspensión con bastante frecuencia. Ahora estoy pensando que esto podría ser un problema del sistema de archivos. No estoy al 100%.

Los sectores defectuosos son siempre una indicación de un HDD defectuoso, de hecho, en el momento en que ve un error de E / S como este, probablemente ya haya perdido / dañado algunos datos. Haga una copia de seguridad si aún no tiene una, ejecute una autocomprobación smartctl -t long /dev/disky verifique los datos SMART smartctl -a /dev/disk. Consigue un reemplazo si puedes.

Los sectores defectuosos no se pueden reparar, solo se reemplazan por sectores de reserva, lo que perjudica el rendimiento del HDD, ya que requieren búsquedas adicionales a los sectores de reserva cada vez que se accede a ellos. Marcar tales sectores como incorrectos en la capa del sistema de archivos ayuda, ya que nunca se accederá a ellos; sin embargo, es difícil determinar qué sectores ya fueron reasignados por el disco, por lo que es probable que el sistema de archivos no sepa evitar la región afectada.

Para hacer el intento de reasignar los sectores, generalmente necesita escribir algo en ellos. Sin embargo, dd( D ISK D estroyer) no siempre funciona, y es muy peligroso: si usted confunde las skipy seekopciones, se puede disparar fácilmente en el pie de skipmesa de ping los Nprimeros bloques de /dev/zeroy escribir un bloque de esa "compensación" por la sector 0 de su disco duro .

Si realmente sabe que desea forzar al sector a sobrescribirse con ceros, debe usar hdparm:

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

Sí, el sector 833192656 también estaba fallando en las pruebas inteligentes. Para escribirle ceros, use --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.

Como medida de seguridad, en hdparmrealidad no escribe nada a menos que pase el --yes-i-know-what-i-am-doinginterruptor 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, los sectores defectuosos no siempre son una indicación de un disco defectuoso. A veces, si hay una escritura en curso en el momento de una falla de energía, los datos en el sector se dañarán, lo que provocará un error cuando intente leerlo. Intentar escribir nuevos datos en el sector puede funcionar bien, ya que no tiene nada de malo físicamente.

Puede ejecutar badblocks -nen el disco para leer y reescribir cada sector, o en su caso, dado que ya conoce el número del sector en cuestión, puede usarlo ddpara escribir ceros en él. Puede consultar las estadísticas SMART con smartctl -a. Debería ver que el recuento reasignado pendiente indica cuántos sectores no han podido leer, y después de intentar escribir el sector, este recuento disminuirá. El recuento de sectores reasignados puede aumentar, en cuyo caso fue físicamente malo y se ha reasignado al grupo de repuesto, y esto puede ser una señal de que la unidad está saliendo. Si no, entonces estaba revuelto y debería estar bien ahora.

Intenta leer el sector primero:

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

Si eso falla, entonces tiene el número correcto, entonces puede ponerlo a cero con:

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

Comprueba que escribiste el comando exactamente antes de presionar enter.