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

16

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%.

MrNorm
la source
4
C'est presque / certainement / un signe pour vous assurer que vos sauvegardes sont en ordre, puis vérifiez votre matériel.
Shadur
Hmm. Ils sont un peu dépassés mais ils sont là malgré tout. Très frustrant, car ce disque a remplacé un autre défectueux.
MrNorm
Les disques échouent, voir ces Q&R où j'ai expliqué
slm
2
... Si ce disque a remplacé un disque défectueux, il est possible que ce soit le contrôleur plutôt que le disque.
Shadur

Réponses:

17

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.

frostschutz
la source
Merci. Vraiment utile de le savoir car cela a toujours été une zone grise pour moi. Je vais remettre le lecteur à zéro et le renvoyer, car il est sous garantie.
MrNorm
1
Mais non. Les secteurs défectueux indiquent simplement un trafic extrêmement élevé vers un secteur. Dans la plupart des cas, cela indique un disque défaillant. Vous pouvez régler votre vitesse de recherche pour marquer les réponses plus lentes comme étant mauvaises ... C'est trop complexe pour dire toujours.
RobotHumans
2
Des erreurs de lecture peuvent également apparaître pour un système de fichiers qui, pour une raison quelconque, est plus grand que le disque réel.
Thorbjørn Ravn Andersen
@frostschutz quel est le sens de Get a replacement if you can.? voulez-vous dire remplacer le disque?
avion
10

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

%
Antti Haapala
la source
Bien qu'il s'agisse d'une ancienne réponse, je me demande vraiment ce que vous entendez par «dd ne fonctionne pas toujours». Suggérez-vous qu'il pourrait ne pas écrire les données comme indiqué? Il ne fait rien de particulièrement sujet à l'échec, il suffit de copier des données. Vous pouvez obtenir le même résultat en utilisant deux lignes dans presque tous les langages de programmation.
TooTea
7

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.

psusi
la source
Il est intéressant que vous le disiez, car j'ai obtenu des informations intéressantes à la suite de vos commandes. J'ai modifié ma question ci-dessus.
MrNorm
Votre lecteur ne prend-il pas en charge SMART pour une raison quelconque ou pourquoi n'avez-vous pas encore vérifié cela?
frostschutz
1
@frostschutz "Sur les deux points, le Reallocated_Sector_Ct est resté à 0." Il semble que l'OP ait vérifié SMART.
un CVn
@MrNorm, veuillez ajouter la smartctl -asortie complète à votre question.
psusi
2
Veuillez ne pas utiliser cela (cela ne fonctionne même pas toujours), et si vous confondez sauter et chercher, vous écraserez votre MBR à la place. Voir ma réponse
Antti Haapala