Question hdparm et dd

Support Debian
#1

bonjour, sur un disque, j’avais le nombre des secteurs illisibles en attente de réallocation > 30 depuis un certain temps et j’ai décidé de les remettre en service (tans pis pour les données) avec des opérations d’écritures

j’effectue donc des auto-test en mode extended successifs avec SMARTMONTOOLS pour identifier ces secteurs, il n’en reste plus que 8 au moment ou je poste.

197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 8

1 Extended offline Completed: read failure 40% 18213 333987117

j’effectue la commande:

hdparm --write-sector 333987117 --yes-i-know-what-i-am-doing /dev/sda`

/dev/sda:
re-writing sector 333987117: succeeded

le secteur est bien décrémenté de la liste des secteurs Current_Pending_Sector
et donc remis en service normalement, et si j’ai bien compris une erreur d’écriture aurait ré-alloué ce secteur dans la zone de réserve, n’est ce pas ?

mais je viens de constater ceci:

dd if=/dev/sda bs=512 count=1 skip=333987117 | hexdump -C
dd: erreur de lecture « /dev/sda »: Erreur d’entrée/sortie
0+0 enregistrements lus
0+0 enregistrements écrits
0 octet (0 B) copié, 5,74407 s, 0,0 kB/s

ainsi que:

dd if=/dev/zero of=/dev/sda obs=512 count=1 seek=333987117
dd: écriture vers « /dev/sda »: Erreur d’entrée/sortie
1+0 enregistrements lus
0+0 enregistrements écrits
0 octet (0 B) copié, 5,43338 s, 0,0 kB/s

pourquoi hdparm peut lire/écrire sur ce secteur alors qu’il y a une erreur entré/sortie avec dd ?

je risque donc un jour ou l’autre de voir réapparaitre ces secteurs dans la liste des Current_Pending_Sector…

#2

Le secteur n’a pas forcément été réalloué, il a pu être simplement réécrit sur place. La décrémentation de Current_Pending_Sector ne veut pas non plus dire que le secteur a été réparé mais seulement qu’on n’est plus en attente (pending) de l’ancien contenu puisque le secteur a été réécrit. Regarde aussi si Reallocated_Sector_Count s’est incrémenté.

As-tu vérifié que hdparm --read-sector pouvait bien relire le secteur sans erreur ?
La lecture normale avec dd ou autre lit plusieurs secteurs à la fois même si on n’en demande qu’un, il se peut que le secteur réécrit ne soit pas le seul secteur défectueux car il est assez courant que plusieurs secteurs consécutifs soient défectueux.

#3

aucun n’a été ré-alloué, mais décrémenté seulement, en effet hdparm pouvait relire sans erreur mais pas dd.

> La lecture normale avec dd ou autre lit plusieurs secteurs à la fois même si on n'en demande qu'un

tu es certain ? bs indique exactement les 512 octets… je vais explorer cette piste mais je préférais que la raison soit autre , cela voudrait dire que dd n’est pas fiable et je préfère écarter cette hypothèse.
dd if=/dev/sda bs=512 count=1 skip=331472184 | hexdump -C

merci pour ta réponse.

#4

Oui, je suis certain. La taille de bloc spécifiée par l’option bs= ne concerne que l’application, pas les couches sous-jacentes. Et comme la lecture d’un bloc de secteurs se fait avec une seule commande ATA, un seul secteur illisible provoque l’échec de toute la commande. Il est possible que l’option oflag=direct (E/S directes) provoque des E/S de la taille spécifiée par bs, mais je n’en ai pas la certitude.

Dans le doute tu peux lire au moins les 7 secteurs suivants un par un avec hdparm pour voir si l’un d’eux est défectueux.

#5

c’est exact, il y avait aussi des autres secteurs consécutifs illisibles ( mais non indiqués par les autotest SMART) , je l’ai tous réécrit avec hdparm et dd peut les lire aussi maintenant.

Merci PascalHambourg, tu connais bien le sujet.

#6

Je pense que les autotests SMART s’arrêtent à la première erreur rencontrée.

Se méfier aussi des disques au format avancé “512e” qui ont des secteurs logique de la taille habituelle 512 octets mais des secteurs physiques de 4096 octets, regroupant 8 secteurs logiques. Je me demande comment se passent la lecture et l’écriture dans un secteur logique lorsque le secteur physique qui le contient est défectueux.

#7

oui l’autotest stoppe à chaque secteur illisible en indiquant le secteur et le pourcentage/d’analyse qui restait à effectuer:
Extended offline Completed: read failure 90% 18220 461601966

sur le disque que je viens d’intervenir avec ces secteurs défecteux:
Sector Size: 512 bytes logical/physical

par contre j’ai un autre disque qui indique effectivement :
Sector Sizes: 512 bytes logical, 4096 bytes physical
(celui du post SMART error (OfflineUncorrectableSector) detected on host)

#8

une dernière question PascalHambourg:

La taille de bloc spécifiée par l'option bs= ne concerne que l'application, pas les couches sous-jacentes. Et comme la lecture d'un bloc de secteurs se fait avec une seule commande ATA, un seul secteur illisible provoque l'échec de toute la commande.

en cas d’écriture comment cela se passe t’il ? dd ne peux pas se permettre “d’empiéter sur des autres secteurs” ?
un seule commande ATA pour sélectionner un bloc, mais il faut bien qu’il délimite exactement les 512 octets concernés

#9

J’ignore comment cela se passe avec l’écriture. En tout cas ce n’est pas dd qui s’en préoccupe ; il indique juste le nombre d’octets à lire ou écrire au noyau et c’est ce dernier qui se débrouille. Même chose si la position n’est pas alignée avec une limite de secteur ou de bloc. Si nécessaire, le noyau lit un bloc plus grand, modifie les octets à écrire et réécrit le tout.

#10

Je pense qu’on peut assimiler ça à un montage raid, si un secteur physique est “hs” il y a encore les 3 autres pour indiquer que le secteur logique est encore correct. (redondance des données et meilleure correction d’erreur)

#11

Je ne vois pas le rapport avec le RAID. Logiquement la redondance (ECC) s’applique au secteur physique entier, pas aux secteurs logiques individuels.

#12

C’était simplement une analogie.

la redondance (ECC) s’applique au secteur physique entier

c’est bien le cas, mais que veux tu dire par entier ?
J’y vois une “autre” redondance sur les 4 secteurs physiques
voyons ce que raconte exactement wikipédia…

#13

Quels 4 secteurs physiques ? Je ne parle que d’un secteur physique qui contient 8 secteurs logiques (cf. section “512e” de l’article). Chaque secteur physique est indépendant et a son propre bloc ECC (cf. section “Overview” de l’article).

#14

en fait je m’étais mal exprimé (surtout que j’avais inversé secteur physique et logique), ce que je voulais dire, c’est que pour le noyau, un secteur ne fera toujours que 512 octets alors si “matériellement” celui-ci en fait réellement 4096 (8 secteurs logiques de 512 o) c’est au bénéfice d’une meilleure correction d’erreur et d’une ‘redondance’ pour les données, je ne sais pas si le terme redondance est adéquat mais bon…
le format dit avancé ne donne pas plus de capacité au disque, mais plus d’octets disponibles pour un meilleur asservissement de chaque secteur physique.
A ma première approche, si un secteur physique est déclaré défectueux, c’est vraiment que plusieurs de ses secteurs logiques ont ‘foirés’ aussi.
merci à toi PascalHambourg . bonne soirée.

#15

Bien sûr. C’est la redondance sous une certaine forme qui permet la détection et la correction d’erreur.
Tu parlais du RAID qui a aussi de la redondance mais d’une autre forme, dont le but n’est pas la détection ou la correction d’erreur.

Si, il permet d’augmenter légèrement la capacité utile pour une même capacité brute en économisant l’espace occupé par les blocs de synchro et d’ECC.

Je pense plutôt que tous ses secteurs logiques apparaîtront comme défectueux aussi.