specifier une zone d'un disque pour travailler dessus

Désolé pour le délai, j'ai été un peu occupé.

Th.A.C a écrit :

Le 07/08/2010 00:30, Pascal Hambourg a écrit :

Quand on demande à lire un secteur défaillant, des erreurs de lecture se
produisent et le contrôleur intégré doit faire plusieurs tentatives de
lecture avant d'y parvenir éventuellement ; ça prend du temps et ça fait
chuter le débit effectif. Ensuite quand on demande à écrire sur ce
secteur, il peut se passer deux choses :
- le secteur est laissé sur place et la réécriture le renforce, il
devient donc facile à lire et le débit redevient normal ;

je me suis également demandé si le fait d'écrire un nombre conséquent de
secteurs en une seule fois ne permettrait pas de rééquilibrer les
secteurs, c'est à dire de les repositionner petit à petit de facon plus
régulière et par conséquence faire pareil pour la zone tampon qui se
trouve entre chaque secteur?

Tu parles du décalage latéral de la magnétisation par rapport à l'axe
longitudinal de la piste résultant de l'imprécision de positionnement du
bras de tête lors de l'écriture ?
J'avoue que je ne m'étais pas posé la question, et je n'ai pas de
réponse. J'aurais tendance à penser que la précision de positionnement
est suffisante pour que ce ne soit pas un problème.

- l'emplacement est trop endommagé et le secteur est réalloué dans un
secteur de réserve situé ailleurs ; lors d'un accès séquentiel
ultérieur, il faudra donc que la tête de lecture fasse un crochet pour
accéder à ce secteur et ça fait chuter le debit effectif.

je pensait plutot à des chutes très importantes qui sont plutot dues à
des difficultés de lecture (le disque doit certainement repositionner sa
tête et tenter une autre lecture ou bien il n'arrive pas à lire une
piste entière en une seule fois et met donc plusieurs tours au lieu d'un
seul).
J'ai quelques disques ou j'ai 'vu' la réallocation de secteurs se faire,
mais la chute de débit était très modérée (moins de 20%)

Après la réallocation ? 20 % ce n'est quand même pas négligeable.

Sur les vieux disques (idem pour les disquettes), on avait quelques fois
un entralacement des secteurs pour laisser à l'électronique (ou au
système...) le temps de lire/écrire.
Je suppose qu'aujourd'hui ca n'existe plus, mais comme les disques
actuels sont devenus des boites noires... :-)

Ça n'aurait guère d'intérêt aujourd'hui où les données sont bufferisées
et transférées en DMA, et ça ferait baisser le débit séquentiel. Mais
j'ai connu des systèmes 8 bits dont le processeur n'était pas assez
rapide pour traiter les données d'un lecteur de disquettes double
densité sans entrelacement.

xtof pernod a écrit :

Pascal Hambourg a fait rien qu'à écrire:

Th.A.C a écrit :

Le 06/08/2010 18:18, Fabien LE LEZ a écrit :

Si un bloc est suspect, n'est-ce pas une raison suffisante pour
changer le disque immédiatement ?

Dans un usage professionnel, certes, ça ne vaut pas le coup (ni le coût)
de perdre du temps là-dessus. On remplace et on jette. Mais à titre

Ouaip.. Mais quel gachis. "Ca formate pas ? Ca installe pas ? Tu jettes."

Je suis bien d'accord, mais il y a aussi la logique économique qui
prévaut dans un cadre professionnel où le temps et les données c'est de
l'argent : "ça coûte plus cher à réparer qu'à remplacer, et même si on
peut réparer il y a un risque sur la fiabilité ? on jette".

personnel, ça peut être intéressant. J'ai "sauvé" à grands coups de
cycles de lecture/écriture plusieurs disques récupérés avec un certain
nombre de secteurs en piteux état qui fonctionnent sans souci depuis.

(depuis) combien de temps ? Je suis toujours parti du principe (peut-être
à tort) qu'un disk qui commençait de battre de l'aile, ça présageait rien
de bon sur son avenir (et donc pas de remise en exploit').

Plusieurs années en temps total, mais ils ne fonctionnent pas en
permanence. Je n'ai pas de certitude sur la cause des secteurs
défectueux, n'étant pas l'utilisateur originel de ces disques, mais je
soupçonne qu'il s'agissait d'une cause extérieure comme une alimentation
fluctuante ou une température excessive.

Normalement, le smart s'en occupe. Le disque a des secteurs de réserve.

Oui, mais le contrôleur n'arrive pas toujours à identifier les secteurs
douteux et à les réparer ou réallouer de façon transparente. Il faut

Quand le kernel dit "read|seek error at LBA sector 0123456789",
c'est donc pas plus fiable / exact que ça ?

Ah si, c'est fiable. Mais quand on en est là, c'est déjà trop tard :
sauf erreur transitoire ou coup de bol, le contenu du secteur est perdu.

parfois l'aider un peu.

Ah:
Est-ce que tu peux détailler la manip.. smartmontools, hdparm, outil maison ?
Petits-doigts-musclés + feeling ?

Il faut un peu de tout ça.
Le postulat de base, c'est que le contrôleur intégré du disque ne peut
réallouer un secteur défectueux (illisible) que si d'une part il s'est
rendu compte que le secteur est défectueux, soit à l'occasion d'une
commande de lecture soit d'un test SMART, et si d'autre part on lui
demande de le réécrire avec une commande d'écriture. En effet pour qu'un
secteur soit réalloué de façon transparente il faut qu'il soit encore un
peu lisible afin que les données puissent être recopiées dans le nouvel
emplacement.

Donc en gros :
1) Lecture des secteurs pour que le contrôleur identifie les secteurs
illisibles et les marque "pending".
2) Ecriture des secteurs défectueux qui devrait soit les réparer sur
place soit les réallouer
3) Contrôler le résultat avec smartctl et recommencer si nécessaire,
tant qu'il reste des secteurs illisibles et des secteurs de réserve.

Si veut faire simple et sûr et qu'on n'est pas pressé, on passe tout le
disque à chaque fois. Sinon, on se débrouille pourne passer que sur les
secteurs détectés comme illisibles (et un peu autour).

On peut utiliser dd ou badblocks pour la lecture et l'écriture. Je
n'utilise pas badblocks en mode écriture (-w) pour la réparation car il
fait l'écriture et la lecture en une même exécution et il n'est pas
possible de consulter les attributs SMART entre les deux (et en plus il
peut être très lent).

Avec dd, j'ajoute l'option conv=noerror pour qu'il ne s'arrête pas à la
première erreur, et je spécifie une taille de bloc de 1024 au moins car
sur certaines machines la taille par défaut de 512 provoque une baisse
importante du débit séquentiel.

# en lecture
dd if=/dev/<disque> of=/dev/zero bs@96 conv=noerror
# en écriture
dd if=/dev/zero of=/dev/<disque> bs@96 conv=noerror

Ce serait peut-être mieux d'écrire des valeurs pseudo-aléatoires avec
/dev/urandom plutôt que des zéros avec /dev/zero, mais c'est beaucoup
trop lent.

smartctl -A permet d'afficher les attributs SMART. Il y en a deux
intéressants pour l'opération à consulter après chaque passe de lecture
et d'écriture :
- pending sector count, dont la valeur brute qui indique le nombre de
secteurs connus comme actuellement illisibles
- reallocated sector count, dont la valeur brute indique le nombre total
de secteurs ayant été réalloués, et la valeur normalisée indique
indirectement le taux de secteurs de réserve encore disponibles.

Evidemment, le contenu du disque est perdu. Il ne s'agit pas de
récupérer les données illisibles mais de retrouver un disque opérationnel.

Et aussi, est-ce que ça marche si tu montes le disk avec un adaptateur USB..

J'ai peur que non si on utilise le disque comme un une mémoire de masse
(mass storage) USB.

Ensuite quand on demande à écrire sur ce
secteur, il peut se passer deux choses :
- le secteur est laissé sur place et la réécriture le renforce, il
devient donc facile à lire et le débit redevient normal ;
- l'emplacement est trop endommagé et le secteur est réalloué dans un
secteur de réserve situé ailleurs ;

Ca, tu le vois en demandant le log du S.M.A.R.T du périph ?..

Je le déduis en comparant les attributs SMART pending et reallocated
sector count avant et après : la différence entre la diminution de
pending et l'augmentation de reallocated correspond a priori aux
secteurs non réalloués donc réécrits sur place.

xtof pernod a écrit:

Pascal Hambourg a fait rien qu'à écrire:

Th.A.C a écrit :

Le 06/08/2010 18:18, Fabien LE LEZ a écrit :

Si un bloc est suspect, n'est-ce pas une raison suffisante pour
changer le disque immédiatement ?

Dans un usage professionnel, certes, ça ne vaut pas le coup (ni le coût)
de perdre du temps là-dessus. On remplace et on jette. Mais à ti tre

Ouaip.. Mais quel gachis. "Ca formate pas ? Ca installe pas ? Tu jett es."

C'est une question de coût. Combien coûte un informaticien qui pass e une
journée à réparer un disque ? Combien coûte un disque ? En enco re, là, je
suppose que le disque a pu être réparé et continue de fonctionner .

J'ai même vu quelqu'un m'expliquer que lors d'un déménagement, il coûtait
moins cher de jeter les meubles des anciens locaux et de faire livrer d es
meubles neufs dans les nouveaux locaux que de payer des déménageurs pour
transporter les meubles.

Le 12/08/2010 14:35, Pascal Hambourg a écrit :

je me suis également demandé si le fait d'écrire un nombre conséquent de
secteurs en une seule fois ne permettrait pas de rééquilibrer les
secteurs, c'est à dire de les repositionner petit à petit de facon plus
régulière et par conséquence faire pareil pour la zone tampon qui se
trouve entre chaque secteur?

Tu parles du décalage latéral de la magnétisation par rapport à l'axe
longitudinal de la piste résultant de l'imprécision de positionnement du
bras de tête lors de l'écriture ?
J'avoue que je ne m'étais pas posé la question, et je n'ai pas de
réponse. J'aurais tendance à penser que la précision de positionnement
est suffisante pour que ce ne soit pas un problème.

oui, je ne me rappelle plus bien la structure exacte, mais de mémoire,
on avait un identificateur du secteur, le secteur lui-même et une zone
tampon servant à 'absorber' les différences de temps (la durée) entre
lecture et écriture.

- l'emplacement est trop endommagé et le secteur est réalloué dans un
secteur de réserve situé ailleurs ; lors d'un accès séquentiel
ultérieur, il faudra donc que la tête de lecture fasse un crochet pour
accéder à ce secteur et ça fait chuter le debit effectif.

je pensait plutot à des chutes très importantes qui sont plutot dues à
des difficultés de lecture (le disque doit certainement repositionner sa
tête et tenter une autre lecture ou bien il n'arrive pas à lire une
piste entière en une seule fois et met donc plusieurs tours au lieu d'un
seul).
J'ai quelques disques ou j'ai 'vu' la réallocation de secteurs se faire,
mais la chute de débit était très modérée (moins de 20%)

Après la réallocation ? 20 % ce n'est quand même pas négligeable.

ca doit dépendre de la position du secteur de secours utilisé par
rapport à celui remplacé. Je suppose que les secteurs de secours sont
répartis sur tout le disque pour éviter des aller/retour de tête.

Sur les vieux disques (idem pour les disquettes), on avait quelques fois
un entralacement des secteurs pour laisser à l'électronique (ou au
système...) le temps de lire/écrire.
Je suppose qu'aujourd'hui ca n'existe plus, mais comme les disques
actuels sont devenus des boites noires... :-)

Ça n'aurait guère d'intérêt aujourd'hui où les données sont bufferisées
et transférées en DMA, et ça ferait baisser le débit séquentiel.

pas sur, il suffit que le disque tourne plus vite et débite plus que
l'interface
ou bien qu'il y ait une lecture alternativement sur plusieurs têtes pour
une même piste.

j'ai connu des systèmes 8 bits dont le processeur n'était pas assez
rapide pour traiter les données d'un lecteur de disquettes double
densité sans entrelacement.

l'amstrad CPC par exemple, mais je suppose qu'une bonne partie des 8
bits avec des lecteurs en DD avaient cette contrainte...
Les utilitaires de formattage cp/m sous dos avaient tous une option pour
ca. :-)

Stephane CARPENTIER a fait rien qu'à écrire:

xtof pernod a écrit:

Pascal Hambourg a fait rien qu'à écrire:

Th.A.C a écrit :

Le 06/08/2010 18:18, Fabien LE LEZ a écrit :

Si un bloc est suspect, n'est-ce pas une raison suffisante pour
changer le disque immédiatement ?

Dans un usage professionnel, certes, ça ne vaut pas le coup (ni le coût)
de perdre du temps là-dessus. On remplace et on jette. Mais à titre

Ouaip.. Mais quel gachis. "Ca formate pas ? Ca installe pas ? Tu jettes."

C'est une question de coût. Combien coûte un informaticien qui passe une
journée à réparer un disque ?

Une journée ? Paye-lui un stage, une formation, un bouquin sur le taylorisme,
parce que c"est de l'acharnement.

Combien coûte un disque ? En encore, là, je
suppose que le disque a pu être réparé et continue de fonctionner.

Ouaip..

J'ai même vu quelqu'un m'expliquer que lors d'un déménagement, il coûtait
moins cher de jeter les meubles des anciens locaux et de faire livrer des
meubles neufs dans les nouveaux locaux que de payer des déménageurs pour
transporter les meubles.

Pas de doute, c'est comme ça qu'il faut faire. Surtout si les déchets sont
pris en charge par les éboueurs, eux-même à la solde du contribuable..

--
christophe. bizness rulez, Coco.

Pascal Hambourg a fait rien qu'à écrire:

xtof pernod a écrit :

Pascal Hambourg a fait rien qu'à écrire:

Th.A.C a écrit :

Le 06/08/2010 18:18, Fabien LE LEZ a écrit :

Si un bloc est suspect, n'est-ce pas une raison suffisante pour
changer le disque immédiatement ?

Dans un usage professionnel, certes, ça ne vaut pas le coup (ni le coût)
de perdre du temps là-dessus. On remplace et on jette. Mais à titre

Ouaip.. Mais quel gachis. "Ca formate pas ? Ca installe pas ? Tu jettes."

Je suis bien d'accord, mais il y a aussi la logique économique qui
prévaut dans un cadre professionnel où le temps et les données c'est de
l'argent : "ça coûte plus cher à réparer qu'à remplacer, et même si on
peut réparer il y a un risque sur la fiabilité ? on jette".

Cette logique est fortement viciée àmha. Il y a des tas de choses qui
ne sont pas prises en compte..

personnel, ça peut être intéressant. J'ai "sauvé" à grands coups de
cycles de lecture/écriture plusieurs disques récupérés avec un certain
nombre de secteurs en piteux état qui fonctionnent sans souci depuis.

(depuis) combien de temps ? (...)

Plusieurs années en temps total, (...)

Appréciable. Ca vaut le coup de s'y pencher.

Quand le kernel dit "read|seek error at LBA sector 0123456789",
c'est donc pas plus fiable / exact que ça ?

Ah si, c'est fiable. Mais quand on en est là, c'est déjà trop tard :
sauf erreur transitoire ou coup de bol, le contenu du secteur est perdu.

En lecture, certes, mais si on le ré-écrit: il repart pour un tour:
0. dans pratiquement tous les cas
1. avec un peu de chance
2. avec pas mal de pot
3. si tu as le derrière bordé de nouilles jusqu'aux oreilles ?

parfois l'aider un peu.

Ah:
Est-ce que tu peux détailler la manip.. smartmontools, hdparm, outil maison ?
Petits-doigts-musclés + feeling ?

Il faut un peu de tout ça.

J'en étais sûr =)

Le postulat de base, c'est que le contrôleur intégré du disque ne peut
réallouer un secteur défectueux (illisible) que si d'une part il s'est
rendu compte que le secteur est défectueux, soit à l'occasion d'une
commande de lecture soit d'un test SMART, et si d'autre part on lui
demande de le réécrire avec une commande d'écriture. En effet pour qu'un
secteur soit réalloué de façon transparente il faut qu'il soit encore un
peu lisible afin que les données puissent être recopiées dans le nouvel
emplacement.

"un peu" lisible ? C'est vrai que le contrôleur fait plusieurs essais, des
fois que le secteur soit 'limite', mais la plupart du temps, foutu, c'est
foutu, non ?..

Donc en gros :
1) Lecture des secteurs pour que le contrôleur identifie les secteurs
illisibles et les marque "pending".

Où est-ce qu'il marque ça, dans les entêtes de secteurs, ou dans ses
tables SMART ? et aussi, par curiosité, où est-ce qu'il loge ses tables,
physiquement parlant:

# smartctl -l directory /dev/sda
SMART Log Directory Logging Version 1 [multi-sector log support]
Log at address 0x00 has 001 sectors [Log Directory]
Log at address 0x01 has 001 sectors [Summary SMART error log]
Log at address 0x80 has 016 sectors [Host vendor specific log]

Dans des secteurs accessibles seulement par le contrôleur ?

2) Ecriture des secteurs défectueux qui devrait soit les réparer sur
place soit les réallouer

Ok..

3) Contrôler le résultat avec smartctl et recommencer si nécessaire,
tant qu'il reste des secteurs illisibles et des secteurs de réserve.

Si veut faire simple et sûr et qu'on n'est pas pressé, on passe tout le
disque à chaque fois. Sinon, on se débrouille pourne passer que sur les
secteurs détectés comme illisibles (et un peu autour).

On peut utiliser dd ou badblocks pour la lecture et l'écriture. Je
n'utilise pas badblocks en mode écriture (-w) pour la réparation car il
fait l'écriture et la lecture en une même exécution et il n'est pas
possible de consulter les attributs SMART entre les deux (et en plus il

Propose un patch, ça peut être interessant:
boucler tant_que(il y a des err.) ou nbre_passes++ < maximum

peut être très lent).

Ah, pourquoi.. Parce qu'il bute de trop sur les secteurs en erreur, ou
l'algo employé est pas top ?

En tout cas, ça rame: (sur un 40Go en usb)
4.65% effectué, 29:11 écoulé
4.66% effectué, 36:18 écoulé

Avec dd, j'ajoute l'option conv=noerror pour qu'il ne s'arrête pas à la
première erreur, et je spécifie une taille de bloc de 1024 au moins car
sur certaines machines la taille par défaut de 512 provoque une baisse
importante du débit séquentiel.

# en lecture
dd if=/dev/<disque> of=/dev/zero bs@96 conv=noerror

Tiens, oui, on peut écrire dans /dev/zero, marrant =) on en apprend tlj.

# en écriture
dd if=/dev/zero of=/dev/<disque> bs@96 conv=noerror

Voila qui m'apparait être quelque peu destructif.. plus que badblocks -w
(mais bon, si le but est de récupérer le disk, et non les données..)

Ce serait peut-être mieux d'écrire des valeurs pseudo-aléatoires avec
/dev/urandom plutôt que des zéros avec /dev/zero, mais c'est beaucoup
trop lent.

Et avec une valeur binaire un peu plus "contrastée", genre 0xa5
(option -t de badblocks), c'est plus 'fiable' ?

smartctl -A permet d'afficher les attributs SMART. Il y en a deux
intéressants pour l'opération à consulter après chaque passe de lecture
et d'écriture :
- pending sector count, dont la valeur brute qui indique le nombre de
secteurs connus comme actuellement illisibles
- reallocated sector count, dont la valeur brute indique le nombre total
de secteurs ayant été réalloués, et la valeur normalisée indique
indirectement le taux de secteurs de réserve encore disponibles.

Evidemment, le contenu du disque est perdu. Il ne s'agit pas de
récupérer les données illisibles mais de retrouver un disque opérationnel.

Et aussi, est-ce que ça marche si tu montes le disk avec un adaptateur USB..

J'ai peur que non si on utilise le disque comme un une mémoire de masse
(mass storage) USB.

En effet:
root@xtof-iv:/home/xtof# smartctl --all /dev/sdb
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
(...)
Device: Hitachi HTS541040G9AT00 Version: A61A
Device type: disk
Local Time is: Fri Aug 13 00:34:24 2010 CEST
Device does not support SMART

Dommage..

Ensuite quand on demande à écrire sur ce
secteur, il peut se passer deux choses :
- le secteur est laissé sur place et la réécriture le renforce, il
devient donc facile à lire et le débit redevient normal ;
- l'emplacement est trop endommagé et le secteur est réalloué dans un
secteur de réserve situé ailleurs ;

Ca, tu le vois en demandant le log du S.M.A.R.T du périph ?..

Je le déduis en comparant les attributs SMART pending et reallocated
sector count avant et après : la différence entre la diminution de
pending et l'augmentation de reallocated correspond a priori aux
secteurs non réalloués donc réécrits sur place.

Ah, très fin. Je vais creuser un peu mieux, je suis pas sur de tout suivre:
. la diminution de pending indique que des erreurs ont été corrigé
(déplacement ou réécriture)
. l'augmentation de reallocated correspond: au nombre de secteurs qui ont
été déplacé, pour corriger les erreurs, ou qu'il est possible de déplacer,
question de capacité de table de réallocation ?

Merci pour ces bonnes infos, en tout cas.. C'est chouette, le SMART. Mais
le mystère est entier: pourquoi on s'en sert (pratiquement) pas, et qu'on
fiche en l'air ces foutus disks, on en revient là.

--
christophe.

xtof pernod a écrit :

Pascal Hambourg a fait rien qu'à écrire:

xtof pernod a écrit :

Quand le kernel dit "read|seek error at LBA sector 0123456789",
c'est donc pas plus fiable / exact que ça ?

Ah si, c'est fiable. Mais quand on en est là, c'est déjà trop tard :
sauf erreur transitoire ou coup de bol, le contenu du secteur est perdu.

En lecture, certes, mais si on le ré-écrit: il repart pour un tour:
0. dans pratiquement tous les cas
1. avec un peu de chance
2. avec pas mal de pot
3. si tu as le derrière bordé de nouilles jusqu'aux oreilles ?

Je n'ai pas fait de statistiques.

En effet pour qu'un
secteur soit réalloué de façon transparente il faut qu'il soit encore un
peu lisible afin que les données puissent être recopiées dans le nouvel
emplacement.

"un peu" lisible ? C'est vrai que le contrôleur fait plusieurs essais, des
fois que le secteur soit 'limite', mais la plupart du temps, foutu, c'est
foutu, non ?..

Avec l'ECC (détection et correction d'erreurs) il y a des degrés dans la
lisibilité d'un secteur :
- immédiate sans erreur d'ECC
- immédiate avec quelques erreurs d'ECC corrigeables
- immédiate avec un nombre limite d'erreurs d'ECC corrigeables
- après plusieurs tentatives avec des erreurs d'ECC non corrigeables

Dans les deux derniers cas, le contrôleur embarqué peut décider qu'il
faut réagir car la prochaine fois il aura peut-être moins de chance. Par
exemple en faisant d'abord une réécriture sur place, vérification et
réallocation si le résultat n'est pas satisfaisant. Tout cela de façon
transparente pour le système hôte à l'exception du temps de lecture qui
peut augmenter.

Donc en gros :
1) Lecture des secteurs pour que le contrôleur identifie les secteurs
illisibles et les marque "pending".

Où est-ce qu'il marque ça, dans les entêtes de secteurs, ou dans ses
tables SMART ? et aussi, par curiosité, où est-ce qu'il loge ses tables,
physiquement parlant:

Je ne suis pas dans le secret des constructeurs, mais je pense que ce
n'est pas dans la carte contrôleur. J'ai eu un disque HS à cause d'un
probable crash de têtes, en tout cas après ouverture j'ai constaté que
la piste extérieure du plateau supérieur était bien labourée. Comme
j'avais un autre disque de la même famille mais pas de la même capacité,
j'ai essayé de monter la carte contrôleur du disque HS sur la mécanique
de l'autre, et j'ai bien retrouvé toutes les caractéristiques de ce
dernier : modèle, numéro de série, capacité... Donc manifestement la
"personnalité" du disque n'était pas dans la carte contrôleur.

Dans des secteurs accessibles seulement par le contrôleur ?

Je pense.

On peut utiliser dd ou badblocks pour la lecture et l'écriture. Je
n'utilise pas badblocks en mode écriture (-w) pour la réparation car il
fait l'écriture et la lecture en une même exécution et il n'est pas
possible de consulter les attributs SMART entre les deux (et en plus il
peut être très lent).

Ah, pourquoi.. Parce qu'il bute de trop sur les secteurs en erreur, ou
l'algo employé est pas top ?

J'en ai eu l'impression. D'un autre côté, c'est son but de détecter les
secteurs défectueux. Ici le but est plutôt de faire comprendre au
contrôleur embarqué qu'un secteur est défectueux (en le lisant) et lui
donner l'occasion de le réparer (en l'écrivant).

# en lecture
dd if=/dev/<disque> of=/dev/zero bs@96 conv=noerror

Tiens, oui, on peut écrire dans /dev/zero, marrant =) on en apprend tlj.

Erreur de copier-coller, c'est /dev/null.

# en écriture
dd if=/dev/zero of=/dev/<disque> bs@96 conv=noerror

Voila qui m'apparait être quelque peu destructif.. plus que badblocks -w
(mais bon, si le but est de récupérer le disk, et non les données..)

Ah çà, j'avais prévenu plus bas. Il ne s'agit pas de récupération de
données. Cela dit la lecture vers autre chose que /dev/null peut être
l'occasion de sauvegarder ce qui est encore lisible pour récupération
ultérieure (en ajoutant l'option sync), même si d'autres outils comme
ddrescue ou myrescue sont plus appropriés pour cela.

Ce serait peut-être mieux d'écrire des valeurs pseudo-aléatoires avec
/dev/urandom plutôt que des zéros avec /dev/zero, mais c'est beaucoup
trop lent.

Et avec une valeur binaire un peu plus "contrastée", genre 0xa5
(option -t de badblocks), c'est plus 'fiable' ?

Je n'ai pas de certitude, désolé. Tout cela est très empirique.
J'utilise badblocks en lecture/écriture à la fin pour une ultime
vérification après que tous les secteurs défectueux aient apparemment
disparu.

Ah, très fin. Je vais creuser un peu mieux, je suis pas sur de tout suivre:
. la diminution de pending indique que des erreurs ont été corrigé
(déplacement ou réécriture)

Disons ces secteurs ont été retirés de la liste des secteurs dont la
lecture a échoué.

. l'augmentation de reallocated correspond: au nombre de secteurs qui ont
été déplacé, pour corriger les erreurs, ou qu'il est possible de déplacer,
question de capacité de table de réallocation ?

La valeur brute est le nombre total de secteurs réalloués. La valeur
normalisée indique le taux de secteurs de réserve restants. En supposant
que c'est linéaire, si la valeur initiale était 100 et que la valeur
actuelle est 95, il reste 95% du stock.

On Thu, 12 Aug 2010 19:05:58 +0200, Stephane CARPENTIER
<stef.carpentier@free.fr>:

J'ai même vu quelqu'un m'expliquer que lors d'un déménagement, il coûtait
moins cher de jeter les meubles des anciens locaux et de faire livrer des
meubles neufs dans les nouveaux locaux que de payer des déménageurs pour
transporter les meubles.

Vu le coût d'un déménagement, je suis tout prêt à le croire.

On 13/08/2010 14:18, Pascal Hambourg wrote:

xtof pernod a écrit :

Pascal Hambourg a fait rien qu'à écrire:

xtof pernod a écrit :

Quand le kernel dit "read|seek error at LBA sector 0123456789",
c'est donc pas plus fiable / exact que ça ?

Ah si, c'est fiable. Mais quand on en est là, c'est déjà trop tard :
sauf erreur transitoire ou coup de bol, le contenu du secteur est perdu.

En lecture, certes, mais si on le ré-écrit: il repart pour un tour:
0. dans pratiquement tous les cas
1. avec un peu de chance
2. avec pas mal de pot
3. si tu as le derrière bordé de nouilles jusqu'aux oreilles ?

Je n'ai pas fait de statistiques.

Du reste, l'échantillon ne serait pas suffisement grand..

En effet pour qu'un
secteur soit réalloué de façon transparente il faut qu'il soit encore un
peu lisible afin que les données puissent être recopiées dans le nouvel
emplacement.

"un peu" lisible ? C'est vrai que le contrôleur fait plusieurs essais, des
fois que le secteur soit 'limite', mais la plupart du temps, foutu, c'est
foutu, non ?..

Avec l'ECC (détection et correction d'erreurs) il y a des degrés dans la
lisibilité d'un secteur :
- immédiate sans erreur d'ECC

Comment détecte-t-il qu'il y a une erreur, dans ce cas.. CRC ?

- immédiate avec quelques erreurs d'ECC corrigeables
- immédiate avec un nombre limite d'erreurs d'ECC corrigeables
- après plusieurs tentatives avec des erreurs d'ECC non corrigeables

Dans les deux derniers cas, le contrôleur embarqué peut décider qu'il
faut réagir car la prochaine fois il aura peut-être moins de chance. Par
exemple en faisant d'abord une réécriture sur place, vérification et
réallocation si le résultat n'est pas satisfaisant. Tout cela de façon
transparente pour le système hôte à l'exception du temps de lecture qui
peut augmenter.

Ok..

Donc en gros : (...badblocks...) >>> peut être très lent).

Ah, pourquoi.. Parce qu'il bute de trop sur les secteurs en erreur, ou
l'algo employé est pas top ?

J'en ai eu l'impression. D'un autre côté, c'est son but de détecter les
secteurs défectueux. Ici le but est plutôt de faire comprendre au
contrôleur embarqué qu'un secteur est défectueux (en le lisant) et lui
donner l'occasion de le réparer (en l'écrivant).

Tûtàfé. Le man dit un truc genre, "don't think you're smarter than
badblocks", ce que je peux aisément concevoir ; d'où, la question.
Mais l'idée d'interroger le SMART entre chaque passe de test, avec
remontée des chiffres, me parait assez bonne..

# en lecture
dd if=/dev/<disque> of=/dev/zero bs@96 conv=noerror

Tiens, oui, on peut écrire dans /dev/zero, marrant =) on en apprend tlj.

Erreur de copier-coller, c'est /dev/null.

Pas de soucis, les lecteurs auront rectifié d'eux-même..
(Et si non, ben ça marche quand même. Etonnant, non.)

# en écriture
dd if=/dev/zero of=/dev/<disque> bs@96 conv=noerror

(...)>

Ce serait peut-être mieux d'écrire des valeurs pseudo-aléatoires avec
/dev/urandom plutôt que des zéros avec /dev/zero, mais c'est beaucoup
trop lent.

Et avec une valeur binaire un peu plus "contrastée", genre 0xa5
(option -t de badblocks), c'est plus 'fiable' ?

Je n'ai pas de certitude, désolé. Tout cela est très empirique.

C'est ce qu'on disait dans le temps -- une diskette défectueuse pouvait
passer au _formatage_ avec la valeur 0x00, alors que les erreurs étaient
détectées avec 0x55, 0xaa, 0xf7 ..

memtest86 emploie ce genre de valeurs, mais la doc' décrit longuement
le pourquoi & le comment; l'efficacité n'est plus à montrer. peut-être
est-ce valable pour les disk(ette)s (?)

(...)
La valeur brute est le nombre total de secteurs réalloués. La valeur
normalisée indique le taux de secteurs de réserve restants. En supposant
que c'est linéaire, si la valeur initiale était 100 et que la valeur
actuelle est 95, il reste 95% du stock.

Ok.. C'est noté =)

--
christophe.

xtof pernod a écrit :

On 13/08/2010 14:18, Pascal Hambourg wrote:

Avec l'ECC (détection et correction d'erreurs) il y a des degrés dans la
lisibilité d'un secteur :
- immédiate sans erreur d'ECC

Comment détecte-t-il qu'il y a une erreur, dans ce cas.. CRC ?

Euh... dans ce cas il n'y a pas d'erreur justement. La donnée brute lue
correspond pile à un code valide.

- immédiate avec quelques erreurs d'ECC corrigeables
- immédiate avec un nombre limite d'erreurs d'ECC corrigeables
- après plusieurs tentatives avec des erreurs d'ECC non corrigeables

[...]

D'un autre côté, c'est [badblocks] son but de détecter les
secteurs défectueux. Ici le but est plutôt de faire comprendre au
contrôleur embarqué qu'un secteur est défectueux (en le lisant) et lui
donner l'occasion de le réparer (en l'écrivant).

Tûtàfé. Le man dit un truc genre, "don't think you're smarter than
badblocks", ce que je peux aisément concevoir ; d'où, la question.

Mais cette phrase concerne seulement l'option -f pour forcer un test
avec écriture sur un volume monté, pas sa capacité de détection des
blocs défectueux.

Ce serait peut-être mieux d'écrire des valeurs pseudo-aléatoires avec
/dev/urandom plutôt que des zéros avec /dev/zero, mais c'est beaucoup
trop lent.

Et avec une valeur binaire un peu plus "contrastée", genre 0xa5
(option -t de badblocks), c'est plus 'fiable' ?

Je n'ai pas de certitude, désolé. Tout cela est très empirique.

C'est ce qu'on disait dans le temps -- une diskette défectueuse pouvait
passer au _formatage_ avec la valeur 0x00, alors que les erreurs étaient
détectées avec 0x55, 0xaa, 0xf7 ..

memtest86 emploie ce genre de valeurs, mais la doc' décrit longuement
le pourquoi & le comment; l'efficacité n'est plus à montrer. peut-être
est-ce valable pour les disk(ette)s (?)

L'encodage d'une disquette est simple et connu, on peut en déduire les
valeurs les plus susceptibles de poser problème ; cela peut être les
valeurs qui entraînent beaucoup de transitions (bande passante élevée),
ou au contraire avec peu de transitions (rendant plus difficile
l'extraction de l'horloge bit). Idem pour la mémoire où des bits voisins
peuvent se parasiter. En revanche l'encodage d'un disque dur actuel est
plus complexe et connu du seul fabricant, donc les valeurs à problème ne
sont pas aussi évidentes à déterminer.