Un secteur défectueux indique-t-il un disque défaillant?

Mon système Ubuntu 13.10 a très mal fonctionné au cours du dernier jour environ. En regardant les journaux du noyau, il semble que le disque SATA <1 an ancien 3 To a des problèmes avec un secteur particulier:

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

Le kern.logfichier fait environ 33 Mo, le plus souvent rempli de l'erreur répétée ci-dessus et le secteur ne semble pas différent dans les messages répétés.

J'exécute actuellement la commande suivante sur le disque maintenant non monté pour tester et tenter de résoudre tous les problèmes que le disque pourrait avoir. Je suis environ 12 heures et je m'attends à ce que cela prenne encore 24/48 heures car le disque est si gros:

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

Ma question est: est-ce que ce disque tombe en panne, ou est-ce que je regarde un problème commun ici? Je me demande s'il est utile de réparer ou d'ignorer les secteurs défectueux et si je devrais remplacer le disque sous garantie pendant qu'il est encore couvert. Ma connaissance de la commande ci-dessus fait quelque peu défaut, donc je suis sceptique quant à savoir si cela peut aider ou non.

Mise à jour rapide!

e2fsck a finalement terminé après 2 jours avec beaucoup de "bloc (s) multiplié (s) dans l'inode". La tentative de montage du système de fichiers a entraîné une erreur, le forçant à revenir en lecture seule:

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

Essayer de lire le secteur manuellement:

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

Essayer d'écrire dessus:

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

Sur les deux points, le Reallocated_Sector_Ct0 est resté.

Le lecteur passe assez souvent en veille. Je pense maintenant que cela pourrait être un problème de système de fichiers? Je ne suis pas à 100%.

Les secteurs défectueux sont toujours une indication d'un disque dur défaillant, en fait, au moment où vous voyez une erreur d'E / S comme celle-ci, vous avez probablement déjà perdu / corrompu certaines données. Faites une sauvegarde si vous ne l'avez pas déjà fait, lancez un auto-test smartctl -t long /dev/disket vérifiez les données SMART smartctl -a /dev/disk. Obtenez un remplacement si vous le pouvez.

Les secteurs défectueux ne peuvent pas être réparés, seulement remplacés par des secteurs de réserve, ce qui nuit aux performances du disque dur, car ils nécessitent des recherches supplémentaires dans les secteurs de réserve à chaque accès. Marquer de tels secteurs comme mauvais sur la couche du système de fichiers est utile, car ils ne seront jamais accessibles à ce moment-là; cependant, il est difficile de déterminer quels secteurs ont déjà été réalloués par le disque, il est donc probable que le système de fichiers ne saura pas éviter la région affectée.

Pour accélérer la réallocation des secteurs, vous devez généralement y écrire quelque chose. Cependant, dd( D ISK D estroyer) ne fonctionne pas toujours, et il est très dangereux: si vous confondez les skipet les seekoptions, vous pouvez facilement vous tirer dans le pied par skipping les Npremiers blocs de /dev/zeroet écrire un bloc de cette « offset » sur la secteur 0 de votre disque dur .

Si vous savez vraiment que vous voulez forcer le secteur à être remplacé par des zéros, vous devez utiliser hdparm:

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

Oui, le secteur 833192656 échouait également dans les tests intelligents. Pour y écrire des zéros, utilisez --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.

Par mesure de sécurité, hdparmn'écrit vraiment rien sauf si vous passez le --yes-i-know-what-i-am-doingcommutateur à 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

%

Non, les secteurs défectueux ne sont pas toujours une indication d'un lecteur défaillant. Parfois, si une écriture est en cours au moment d'une panne de courant, les données du secteur sont corrompues, ce qui entraîne une erreur lorsque vous essayez de la lire. Tenter d'écrire de nouvelles données dans le secteur peut très bien fonctionner car il n'y a rien de mal physiquement.

Vous pouvez exécuter badblocks -nsur le lecteur pour lire et réécrire chaque secteur, ou dans votre cas, puisque vous connaissez déjà le numéro du secteur en question, vous pouvez utiliser ddpour y écrire des zéros. Vous pouvez consulter les statistiques SMART avec smartctl -a. Vous devriez voir le nombre de réallocations en attente indiquer le nombre de secteurs qui n'ont pas pu lire, et après avoir tenté d'écrire le secteur, ce nombre diminuera. Le nombre de secteurs réaffectés peut augmenter, auquel cas il était physiquement mauvais et a été remappé sur le pool de rechange, et cela peut être un signe que le lecteur est sur le point de sortir. Sinon, alors c'était juste brouillé et ça devrait aller maintenant.

Essayez d'abord de lire le secteur:

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

Si cela échoue, alors vous avez le bon numéro, vous pouvez le mettre à zéro avec:

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

Vérifiez que vous avez tapé la commande exactement avant d'appuyer sur Entrée.