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 
[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.
Oui disons que c’est “une sorte de super blacklist” alors. 
C’est clair que sur 3 To ou beaucoup moins, un secteur n’est pas lu ou écrit tous les “quatre matins”.
il a le temps de “mourir”, de passer par des stades “semi-déffecteux” sans que SMART ne s’en apperçoive.
Il faudrait peut être prendre la peine de lire un disque dur en entier régulièrement, pour éviter ce genre de problème, ou du moins en réduire la probabilité.
Ou mieux, en lire une partie différentes régulièrement, jusqu’à avoir lu le disque en entier, et recommencer…
PS : Le “cd Seagate” devrait probablement proposer à vv222 de réallouer ces 32 “Uncorrectable Sector Count” au niveau disque.
[quote=“vv222”]Un badblocks en lecture (via e2fsck -c /dev/sdb1) n’ayant rien corrigé
(…)
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.[/quote]
Si le disque compte plusieurs partitions, tous les secteurs défectueux ne sont pas forcément situés dans la partition vérifiée par fsck.
D’autre part, fsck ne compte pas en secteurs mais en blocs dont la taille est définie dans le système de fichiers (voir [mono]tune2fs -l[/mono]). Typiquement, pour un volume de taille classique, la taille de bloc est 4 Kio soit 8 secteurs de 512 octets.
Si le disque est au “format avancé” avec des secteurs physiques de 4 Kio et des secteurs logiques de 512 octets (voir [mono]hdparm -I[/mono]) et si les 32 secteurs logiques défectueux sont groupés en blocs de 8 secteurs consécutifs, ils correspondent aussi à 4 secteurs physiques. Un secteur physique défectueux rend défectueux les 8 secteurs logiques correspondants.
Une unique partition couvrant tout le disque :
[code]$ fdisk -l /dev/sdb
Disk /dev/sdb: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D1A6206F-F93A-4A4C-B325-B4878B0F90BD
Device Start End Sectors Size Type
/dev/sdb1 2048 5860532223 5860530176 2,7T Linux filesystem[/code]
[quote]D’autre part, fsck ne compte pas en secteurs mais en blocs dont la taille est définie dans le système de fichiers (voir [mono]tune2fs -l[/mono]). Typiquement, pour un volume de taille classique, la taille de bloc est 4 Kio soit 8 secteurs de 512 octets.
Si le disque est au “format avancé” avec des secteurs physiques de 4 Kio et des secteurs logiques de 512 octets (voir [mono]hdparm -I[/mono]) et si les 32 secteurs logiques défectueux sont groupés en blocs de 8 secteurs consécutifs, ils correspondent aussi à 4 secteurs physiques. Un secteur physique défectueux rend défectueux les 8 secteurs logiques correspondants.[/quote]
Ça me paraît en adéquation avec ma situation si j’interprète bien le retour de fdisk.
Auquel cas tous mes secteurs défectueux ont été détectés par badblocks, et seront probablement ré-alloués lors du badblocks en lecture/écriture.
Problème réglé pour moi !
Un badblocks en lecture/écriture (e2fsck -fyvcck), malgré les plus de 50 h qu’il y a passé, n’a pas abouti à la réallocation des secteurs défectueux du disque.
Je vais essayer l’outil du constructeur lorsque j’aurai de nouveau un accès physique à cette machine.
Avec l’option -k (préserver les blocs défectueux existants), cela ne m’étonne pas.
Y a-t-il eu des erreurs de lecture ou d’écriture pendant l’opération ? Sinon, cela veut dire qu’il n’a même pas essayé d’accéder aux secteurs défectueux.
Vérifie si l’outil du constructeur ne risque pas d’écraser le contenu du disque.
Autres outils possibles : [mono]badblocks -w[/mono] ou [mono]hdparm --write-sector[/mono] sur les secteurs défecteux si tu connais leurs adresses LBA. Avertissement habituel : risque de perte de données en cas d’erreur d’utilisation.
Quelques nouvelles au sujet de ce disque :
Après être resté à peu près stable pendant trois~quatre mois (le nombre de secteur défectueux est monté péniblement à 40, 80 puis 120), je viens de me retrouver avec un pic d’erreurs qui a monté ce nombre à plus de 1500 secteurs défectueux.
C’est l’aiguillon qu’il me manquait, et je viens de commander un autre disque (Western Digital Red 3To) pour copier les données contenues sur le disque défectueux, ce qui me permettra de tranquillement essayer les différents outils qui m’ont été proposé dans cette discussion (je pense en particulier à l’outil SeaTools qui m’a été proposé par PengouinPdt) sans peur de perdre de données.
Pendant ce temps le disque défectueux restera démonté pour éviter que sa situation ne s’aggrave. Sa prochaine utilisation sera uniquement pour en copier le contenu sur le nouveau disque avant de tenter de le remettre en bon état.
Je vous tiendrai au courant des résultats, en particulier au sujet de l’efficacité de SeaTools, en espérant que ça facilitera la vie des prochaines personnes qui se retrouveront face à ce genre de problème.
Pour plus de visibilité j’enlève le marqueur “résolu” de cette discussion, et le remettrai une fois le disque de nouveau comme neuf ou au contraire définitivement mort.
Bonsoir,
Tu as choisi un “WD” , j’ai eu affaire à un modèle SATA2 2To, qui présentait un grand nombre d’erreur SMART.
Cependant l’indicateur d’état SMART sur son nombre de cycle (Load_Cycle_Count) est à 1. Il a déja bien servi.
A part un outil DOS pour tester et éventuelement réparer le disque, je n’ai pas trouvé grand chose.
Pour une éventuelle mise à jour des firmware, ça se passe sous Windows, (Pas d’ISO comme chez Seagate).
Un executable qui est sensé voir ça en ligne (a partir d’un disque dur externe usb).
J’ai essayer sur une machine virtulle, mais sans succès…
Je n’ai pas réussi à savoir si de nouveau firmware était disponible pour mon disque dur.
J’ai appelé le SAV “WD”, pour tenter de le savoir, mais sans succès…
Mon interlocuteur m’a affirmé que l’on ne pouvait pas mettre a jour le firmware, j’ai tout de même un gros doute.
Bref, je reste chez Seagate.
Sinon j’ai partiellement solutionné mon affaire en n’allouant pas 300 Go en fin du disque dur, la ou j’ai constaté des erreurs.
C’est un cas très similaire à celui la (grand nombre de Current_Pending_Sector), mais aucune alerte:
https://www.debian-fr.org/badblocks-accelere-le-processus-t50158.html
[quote=“cedric058”]Tu as choisi un “WD” , j’ai eu affaire à un modèle SATA2 2To, qui présentait un grand nombre d’erreur SMART.
Cependant l’indicateur d’état SMART sur son nombre de cycle (Load_Cycle_Count) est à 1. Il a déja bien servi.[/quote]
Pour éviter les mauvaises surprises, je compte tester intégralement le nouveau disque via smartctl et badblocks dès sa réception. Au moindre soupçon d’erreur je le ferai immédiatement échanger.
[quote=“cedric058”]A part un outil DOS pour tester et éventuelement réparer le disque, je n’ai pas trouvé grand chose.
Pour une éventuelle mise à jour des firmware, ça se passe sous Windows, (Pas d’ISO comme chez Seagate).[/quote]
Hors de question que je monte un système DOS ou Windows pour ça, il faudra donc que je me contente du firmware installé au moment de la réception du disque.
Moi pas, ce qui se comprend aisément quand on se rend compte que les problèmes avec mon disque Seagate ont commencé juste après que la garantie ait pris fin.
Mes problèmes avec ce disque ont en effet commencé à se manifester lorsque qu’il a dépassé les 90 % de remplissage, il faudra peut-être que je tente quelque chose dans le genre en utilisant les tests SMART pour repérer les parties “à risques” du disque et en ne les incluant pas dans la partition utilisable.
Pour l’outils dos, j’ai utilisé Unetbootin pour installer FreeDos sur une clé usb.
Pour l’outils dos, j’ai utilisé Unetbootin pour installer FreeDos sur une clé usb.[/quote]
Ah oui, les implémentations libres de DOS m’étaient sorties de la tête au moment de poster mon dernier message. Je garde cette idée dans un coin de ma mémoire, ça me servira probablement dans un avenir plus ou moins lointain.
Il y a du neuf, mais qui me dépasse un peu :
5 Reallocated_Sector_Ct 0x0033 097 097 010 Pre-fail Always - 4408
197 Current_Pending_Sector 0x0012 088 088 000 Old_age Always - 2072
198 Offline_Uncorrectable 0x0010 088 088 000 Old_age Offline - 2072
[/code]
Je ne comprends pas comment le nombre de secteurs ré-alloués peut-être supérieur au nombre de secteurs défectueux.
Je passerai sur le fait que la ré-allocation débute presque six mois après l’apparition des premiers secteurs défectueux, c’est probablement le firmware du disque qui est programmé d’une manière qui m’échappe.
Au passage, j’ai reçu le nouveau disque que j’ai commandé, je vais donc enfin pouvoir faire un backup complet de celui défectueux, ce qui me permettra de tester des manipulations plus “risquées” comme les outils constructeurs qui m’ont été proposés.
Je pense que tu as 4408 secteurs qui ont été réaloués.
+
2072 secteurs “incorrigibles” (SMART n’arrive pas à les lire et ne les réalloue donc pas), il est donc logique qu’ils soient également en attente d’une éventuelle réallocation.
Un lien en Anglais:
http://www.sj-vs.net/forcing-a-hard-disk-to-reallocate-bad-sectors/
Un lien en Français:
http://linuxfr.org/users/zezinho/journaux/secteurs-defectueux
Si les données ne t’importe plus:
Avec les tests “smartctl”, essayes de déterminer l’emplacement des secteurs défecteux.
Un truc qui marche pas trop mal pour tenter de forcer la réalloction d’un secteur (ici le 1261069669 secteur):
[code]# hdparm –read-sector 1261069669 /dev/sdx
J’avais fais un petit script pour “ballayer” une zone plusieur fois de cette manière.
Le mieux aurais été des les lire un par un, puis si erreur il y avait, de l’écrire, mais bon.
J’ai ainsi réussi à mettre à 0 mes “Offline_Uncorrectable”, cependant mes “Current_Pending_Sector” ont “grimpés” en flèche.