DISQUE DUR : erreurs SMART, secteurs illisibles

Salut à tous !

Le démon smartd me signale depuis quelques jours des erreurs sur un de mes disques :

[code]From root@dotslashplay.it Wed Dec 17 00:25:29 2014
Return-Path: root@dotslashplay.it
X-Original-To: root
Delivered-To: root@dotslashplay.it
Received: by dotslashplay.it (Postfix, from userid 0)
id 23C641C09F2; Wed, 17 Dec 2014 00:25:28 +0100 (CET)
To: root@dotslashplay.it
Subject: SMART error (CurrentPendingSector) detected on host: HAL9000
Message-Id: 20141216232529.23C641C09F2@dotslashplay.it
Date: Wed, 17 Dec 2014 00:25:28 +0100 (CET)
From: root@dotslashplay.it (root)

This message was generated by the smartd daemon running on:

host name: HAL9000
DNS domain: [Empty]

The following warning/error was logged by the smartd daemon:

Device: /dev/sdb [SAT], 32 Currently unreadable (pending) sectors

Device info:
ST3000DM001-1CH166, S/N:Z1F24DDA, WWN:5-000c50-04f7c05e5, FW:CC24, 3.00 TB

For details see host’s SYSLOG.

You can also use the smartctl utility for further investigation.
The original message about this issue was sent at Fri Dec 5 22:00:21 2014 CET
Another message will be sent in 24 hours if the problem persists.

From root@dotslashplay.it Wed Dec 17 00:25:30 2014
Return-Path: root@dotslashplay.it
X-Original-To: root
Delivered-To: root@dotslashplay.it
Received: by dotslashplay.it (Postfix, from userid 0)
id 58E8F1C09B3; Wed, 17 Dec 2014 00:25:29 +0100 (CET)
To: root@dotslashplay.it
Subject: SMART error (OfflineUncorrectableSector) detected on host: HAL9000
Message-Id: 20141216232529.58E8F1C09B3@dotslashplay.it
Date: Wed, 17 Dec 2014 00:25:29 +0100 (CET)
From: root@dotslashplay.it (root)

This message was generated by the smartd daemon running on:

host name: HAL9000
DNS domain: [Empty]

The following warning/error was logged by the smartd daemon:

Device: /dev/sdb [SAT], 32 Offline uncorrectable sectors

Device info:
ST3000DM001-1CH166, S/N:Z1F24DDA, WWN:5-000c50-04f7c05e5, FW:CC24, 3.00 TB

For details see host’s SYSLOG.

You can also use the smartctl utility for further investigation.
The original message about this issue was sent at Fri Dec 5 22:00:21 2014 CET
Another message will be sent in 24 hours if the problem persists.[/code]

Erreurs qui sont bien sûr confirmées par smartctl (ID# 197 & 198) :

[code]root@HAL9000:~# smartctl -A /dev/sdb
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
Copyright © 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 104 099 006 Pre-fail Always - 115985942
3 Spin_Up_Time 0x0003 095 094 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 224
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 068 060 030 Pre-fail Always - 64529137937
9 Power_On_Hours 0x0032 086 086 000 Old_age Always - 13128
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 222
183 Runtime_Bad_Block 0x0032 099 099 000 Old_age Always - 1
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 006 006 000 Old_age Always - 94
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 0 0
189 High_Fly_Writes 0x003a 093 093 000 Old_age Always - 7
190 Airflow_Temperature_Cel 0x0022 065 048 045 Old_age Always - 35 (Min/Max 31/39)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 19
193 Load_Cycle_Count 0x0032 063 063 000 Old_age Always - 74130
194 Temperature_Celsius 0x0022 035 052 000 Old_age Always - 35 (0 10 0 0 0)
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 32
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 32
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 9368h+52m+22.997s
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 27501598581
242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 53398844399[/code]

Un badblocks en lecture (via e2fsck -c /dev/sdb1) n’ayant rien corrigé, je me suis mis en tête de corriger ces secteurs manuellement. J’ai donc commencé par une série de tests SMART, qui m’ont permis de trouver le premier bloc illisible :

[code]root@HAL9000:~# smartctl -l selftest /dev/sdb
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
Copyright © 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error

1 Extended captive Completed: read failure 90% 13120 3006367728

2 Short captive Completed: read failure 90% 13120 3006367728

3 Short offline Completed without error 00% 12191 -

[/code]

dd me permet de confirmer que ce bloc ne peut pas être lu :

root@HAL9000:~# dd if=/dev/sdb of=/dev/null ibs=512 count=1 skip=3006367728 dd: erreur de lecture « /dev/sdb »: Erreur d'entrée/sortie 0+0 enregistrements lus 0+0 enregistrements écrits 0 octet (0 B) copié, 2,88819 s, 0,0 kB/s

Je pensais alors utiliser dd pour forcer la réécriture de ce bloc, mais ça m’a juste permis de me rendre compte que l’écriture sur ce secteur est elle aussi impossible :

root@HAL9000:~# dd if=/dev/zero of=/dev/sdb obs=512 count=1 seek=3006367728 dd: écriture vers « /dev/sdb »: Erreur d'entrée/sortie 1+0 enregistrements lus 0+0 enregistrements écrits 0 octet (0 B) copié, 2,89941 s, 0,0 kB/s


La situation ne s’améliore pas, je viens de remarquer que la valeur brute de Seek_Error_Rate est en augmentation constante :

root@HAL9000:~# date && smartctl -A /dev/sdb | grep Seek_Error_Rate jeudi 18 décembre 2014, 18:26:42 (UTC+0100) 7 Seek_Error_Rate 0x000f 068 060 030 Pre-fail Always - 64529139867 root@HAL9000:~# date && smartctl -A /dev/sdb | grep Seek_Error_Rate jeudi 18 décembre 2014, 18:26:45 (UTC+0100) 7 Seek_Error_Rate 0x000f 068 060 030 Pre-fail Always - 64529139874 root@HAL9000:~# date && smartctl -A /dev/sdb | grep Seek_Error_Rate jeudi 18 décembre 2014, 18:26:51 (UTC+0100) 7 Seek_Error_Rate 0x000f 068 060 030 Pre-fail Always - 64529139893

J’en appelle donc à vos conseils, un peu perdu dans ces manipulations qui sont pour moi d’un genre nouveau.

Personnellement, je te conseille très fortement de changer ton disque dur.
Ce n’est jamais bon signe.

[quote=“PengouinPdt”]Personnellement, je te conseille très fortement de changer ton disque dur.
Ce n’est jamais bon signe.[/quote]
C’est bien sûr ce que je vais finir par faire, mais ce n’est pas possible pour l’instant.
Ça coûte cher un disque de 3 To :wink:

quote="vv222"
C’est bien sûr ce que je vais finir par faire, mais ce n’est pas possible pour l’instant.
Ça coûte cher un disque de 3 To :wink:[/quote]

Je suis d’accord avec toi, ça coûte cher !
Est-il sous garantie encore ? si oui, vois auprès du site du fabriquant …
C’est quoi la marque ? parce qu’avec un coup de “chance”, tu pourrais même avoir accès à des outils à graver sur CD, pour le réparer, telle WD ou Seagate.

Parce que malheureusement, tu ne vas pas avoir longtemps le choix - mais je peux me tromper.

En effet, sous garantie constructeur pour encore quelques mois. Merci de m’y avoir fait penser !

Seagate Barracuda 7200.14 - SATA III 6 Gb/s - 3 To

Je ne peux qu’espérer que tu te trompes, mais je ne me fais pas non plus trop d’illusions.
Mais ayant déjà eu des erreurs de ce type sur ce disque que j’avais fini par régler, je ne perds pas encore espoir de renouveler l’exploit.

Seagate : excellent !
Tu as donc l’outil SeaTools à graver sur un CD … reboot dessus.
S’il peut te réparer le disque, il le fera ; sinon, tu auras un code retour d’erreur, qu’il te faudra communiquer à Seagate pour la prise en charge garantie.
Il te faudra peut-être télécharger une ancienne version, car certaines ne démarrent pas ou mal.
C’est expliqué sur la page …

Bon dl, et bon courage.

Merci pour l’outil, je vais essayer ça.

Bon, cette histoire m’aura au moins appris à me servir de parted pour réparer une table de partitions effacée par accident…
Vérifiez toujours au moins trois fois vos options quand vous utilisez dd pour manipuler les secteurs d’un disque :unamused:

Bonsoir,

Mon père a eu le même soucis avec un Seagate Sata 2.
Il n’y a eu aucun problème pour le SAV (avec le code erreur du “CD Seagate”).
En échange il a eu un Sata 3.

Apparemment d’après ce que j’ai pu lire, c’était un problème de firmware qui fatiguait un condensateur du Disque Dur.

Comme j’en avais trois de la même série, j’ai vite mis à jour mes firmwares.
Il faudra d’ailleurs que je vérifie si des nouveaux firmwares sont disponibles pour mes Disques.

Edit :

J’ai été vérifié, pas de nouvelles versions de firmwares pour ma série.
Mais la dernière version du firmware est marqué comme Importante.

Un piste intéressante, merci.
Tu peux m’expliquer comment tu as mis à jour le firmware de tes disques durs ?

Un conseil, si tu a un problème avec ton DD, et qu’avec le code erreur du “CD Seagate” le SAV de Seagate te dit on vous le change, change le.
C’est qu’il a vraiment un problème physique.

C’etait assez simple, tu télécharges un ISO, tu le graves, tu boot dessus …
Bref assez simple.
(Un seul disque Dur sur la carte mère était vivement conseillé)

Dans mon cas c’était “Barracuda12-ALL-CC49.iso”

Bon, au moins une bonne chose de faite : /home déplacée vers un autre disque, et le disque suspect est toujours utilisé mais monté en lecture seule.
Il reste bien ~2 To de musique, émissions de radio, films, jeux et autres photos de l’Antarctique sur la sellette, mais au moins les données auxquelles je tiens vraiment son sagement en sécurité sur un disque qui ignore ce que peut bien être une erreur SMART.

Demain je verrai si l’outil fourni par Seagate réussit à me tirer de là, le remplacement de ce disque risquant de ne pas pouvoir se faire avant plusieurs mois.

fsck -c devrait au moins avoir marqué les blocs contenus dans des secteurs défectueux afin qu’ils ne soit plus utilisés par le système de fichiers. Par contre il ne corrigera pas les secteurs défectueux eux-même, ce n’est pas son rôle.

La tentative d’écriture dans un secteur défecteux devrait forcer sa réallocation dans un secteur de réserve (le stock est intact) par le contrôleur intégré du disque, mais parfois cela ne fonctionne pas, et j’avoue que je ne comprends pas pourquoi.

fsck -c devrait au moins avoir marqué les blocs contenus dans des secteurs défectueux afin qu’ils ne soit plus utilisés par le système de fichiers. Par contre il ne corrigera pas les secteurs défectueux eux-même, ce n’est pas son rôle.[/quote]
Une nouvelle tentative m’a cette fois-ci marqué quatre secteurs défectueux. Mais sur 32 reportés par SMART, ça me paraît étonnamment peu.
À moins que je ne me mélange entre deux unités différentes ?

Un badblocks en lecture/écriture devrait donc forcer la réallocation des secteurs défectueux de mon disque ?
Je pense en lancer un dans quelques jours quand je n’aurai plus besoin de ce disque pour plusieurs jours.

[quote=“PascalHambourg”]
La tentative d’écriture dans un secteur défecteux devrait forcer sa réallocation dans un secteur de réserve (le stock est intact).[/quote]
Salut, où vois-tu cette info ?
Merci :slightly_smiling:

[quote=“ben_raven”][quote=“PascalHambourg”]
La tentative d’écriture dans un secteur défecteux devrait forcer sa réallocation dans un secteur de réserve (le stock est intact).[/quote]
Salut, où vois-tu cette info ?[/quote]
Cette ligne-ci :

0 secteur réalloué, ce qui signale que la réserve n’a pas encore été entamée.

Normalement la technologie SMART fait une sorte de blacklist des secteurs défectueux, le système ne devrait pas les voir (ou pas plus d’une fois).

Un petit lien Wikipedia:
http://fr.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology

Le disque dur de mon père lui signalait le problème avant que le système ne démarre, durant le chargement du BIOS.

SMART n’est pas magicien. Le système hôte verra un secteur défectueux tant qu’il n’aura pas été corrigé d’une façon ou d’une autre. Le disque ne prend jamais l’initiative de réallouer un secteur illisible au risque de perdre des données tant qu’il n’est pas réécrit par le système hôte.

J’ai du mal comprendre.

En effet, j’ai tiré des conclusions trop rapidement.

Disons que SMART prend l’initiative de réallouer des secteurs semi-défectueux si il arrive au moins à les lire.

On dirait que les 32 secteurs défectueux du disque de vv222 n’ont montrés aucun signes de faiblesse, ils n’ont pas eu le temps de passer en “Reallocated Sectors Count”

Tu n’as pas mal compris, ce que tu as mis en gras est juste faux. Wikipédia n’est pas infaillible. Comme tu l’as compris, SMART ne prend pas l’initiative de réallouer un secteur qu’il ne peut pas lire. La réallocation se fait soit lors d’une lecture réussie, soit lors d’une écriture.

PS : SMART n’a pas de blacklist. C’est une notion de système de fichiers.