[gull] smartctl - Offline uncorrectable sectors qui se repare ensuite tout seul ?!?

[Marc SCHAEFER]

Bonjour,

On Thu, May 29, 2025 at 02:43:43PM +0200, Frederic Dumas via gull wrote:
> Device: /dev/sda [SAT], 2 Offline uncorrectable sectors

Je ne connais pas bien SMART, mais j'ai pas mal joué avec les SCSI MODE
PAGES dans les années 90. Le monde PATA/IDE était complètement différent
(lire: nul), mais le monde SATA s'approche de plus en plus des
performances du SCSI des années 90 (command queueing/NCQ, peut-être même
un peu de paramétrisation, ou du SMART car ils ne savent pas faire
mieux, etc). C'est probablement aussi pour ça (et en raison de disques
plus haut de gamme et d'aspects de performance brute) que le SAS a
encore un marché.

Concrètement, en SCSI il y avait pas mal de paramètres configurables
(*), par exemple:

   - combien de réessais avant de déclarer une erreur

   - activer ou non la correction d'erreur par code (**)

   - faut-il réécrire les secteurs écrits, et relus en erreur, et
     combien de fois, ou juste déclarer une erreur d'écriture?

   - faut-il ignorer les erreurs en lecture?

   - à partir de quand remapper un secteur?  ou plutôt réécrire
     dessus et retester?  combien de fois?

(ci-dessus les "fois" s'exprimaient plutôt en temps pour les
applications qui avaient des contraintes de ce type)

Suivant les applications:

   - vidéo brute à 27 MByte/s temps réel (avant les cartes
     de compression MPEG)

   - stockage de données à long terme

   - applications informatiques

on configurait ces paramètres *très* différemment.

> Sans certitude, smart daemon énumère probablement des secteurs
> physiques de 4K, et non des secteurs logique de 512 [octets], qui sinon
> devraient être défectueux par groupe de 8 (c.a.d que le défaut d'un
> secteur physique entraine celui des 8 secteurs logiques qui le
> recouvrent). Mais ce n'est pas le sujet.

En fait, sauf erreur hdparm donnera la taille de bloc brute et
celle montrée à l'OS: je supposerais que si c'est différent, alors
la performance sera mauvaise (cycle RMW). Sous Linux on a plutôt
intérêt à avoir les 2 tailles identiques.  J'aurais tendance à
penser qu'alors les adresses sont en unités montrées à l'OS, sans
en être sûr.  Tu peux aussi consulter les messages de démarrage
du kernel (dmesg) pour voir comment ce disque a été détecté.

Si tu es effectivement dans le cas "interface à l'OS 512 octets, réel
4096 octets", de toute façon, le disque ne peut pas faire autre chose
de que lire (R), modifier (M) et écrire (W) par unité de 4096 octets.
C'est encore plus drôle si tu modifies 1024 octets d'un fichier
à cheval sur deux blocs physiques, ça fait un double RMW.  (***)

> temps pour aller voir. Et aujourd'hui, surprise, ce HDD ne retourne
> plus aucun secteur défectueux, comme si les deux secteurs en question
> étaient redevenus lisibles tout seuls (sur ce HDD, la variable smart 5
> Reallocated_Sector_Ct est à zéro depuis la nuit des temps, le reste
> encore jusqu'à aujourd'hui, ces deux secteurs n'ont donc pas été
> réalloués).

Un des comportements SCSI mentionnés ci-dessus était de ne pas réallouer
tout de suite des secteurs défectueux, mais quand une nouvelle écriture
se produisait, de vérifier si elle avait marché.

Tu n'as je crois pas précisés, mais Linux md RAID peut réécrire tout
seul des blocs mauvais lorsqu'il existe encore une source correcte
(p.ex. en RAID1): normalement il fait un log kernel.  Il peut même dans
ses dernières versions gérer une reallocation list, si le disque dit que
sa table de réallocation est pleine et que l'écriture rate [1].

Peut-être c'est ce qui a corrigé ton bug?

> tout seuls me parait curieux. Il me semble que cette variable
> s'incrémente seulement quand un secteur est tellement chroniquement
> illisible, que le firmware ne peut procéder à son remplacement
> automatique par un secteur de réserve, n'est-ce pas ?

Il y a deux cas:

   - un secteur est illisible: il n'est pas remappé, l'erreur
     doit rester tant qu'on ne l'a pas réécrit

   - un secteur ne peut être écrit (la vérification après écriture
     a raté): ici il peut être remappé

> forcer sa réallocation, il est alors nécessaire d'intervenir à la main
> à coup de hdparm --yes-i-know-what-i-am-doing --write-sector.

En cherchant un peu, il semblerait que SMART est implémenté un peu
bizarrement, mais cela ne m'étonne pas plus que ça:

   - en théorie, Pending sectors seraient des secteurs mauvais qui
     en cas de réécriture pourraient être soit considérés ok
     (donc Pending sectors serait décrémenté) ou mauvais et donc
     réalloués (aussi décrémenté, mais Reallocated Sectors augmenté)

   - mais en pratique certains fabricants peuvent aussi utiliser
     Offline Uncorrectable à la place?

Donc, en théorie en forçant une écriture, on aurait soit un bloc
de nouveau correct, soit une réallocation et un nouveau bloc
utilisable.

En lisant un peu au hasard sur Internet, on voit aussi que la
recommandation n'est jamais de consulter les valeurs absolues SMART mais
de s'intéresser aux variations.  Et quand ça varie trop, remplacer le
disque.

Un indicateur que je trouve plus fiable que le SMART c'est la
performance des disques telle que mesurée par le kernel (surtout la
latence).  munin permet assez facilement de voir ça, et quand ça monte
... c'est le moment de remplacer.  Ca indique que le disque fait des
trucs (recalibration, relectures, réécritures, réallocations) qui vont
finir mal.  En SCSI il y avait toutes sortes de compteurs pour ça,
et toutes sortes de façon d'influence (style enlever le réessai,
pour relire le disque et voir ce qui plante).  En SATA il semble
qu'on soit partiellement aveugle et les deux mains attachées
dans le dos.

PS: en ce qui me concerne, de plus en plus, je déploie des couches
    d'intégrité en plus de la détection d'erreur des disques
    que cela soit brtfs, zfs, ou le plus performant et "UNIX en
    couche": ext4 sur LVM sur md RAID sur integrity; par contre je
    n'ai pas encore essayé de reformatter un disque
    pour stocker un CRC ou un hachage directement après la fin
    du bloc logique de 512 ou 4096 octets, ce qui évite de
    perdre de la place et de la performance et permet de vérifier
    end-to-end l'intégrité (sauf erreur standard SCSI T10 DIF/DIX [2]
    qui est implémenté similairement dans les NVMe par exemple)

(*) on peut supposer qu'aujourd'hui ces configurations sont disponibles
    comme produits spécifiques (WD blue, verts, etc), mais je n'ai
    pas creusé si c'est paramétrable via un standard ouvert.

(**) aussi appelée FEC/ECC
     c'était pratique quand je gravais en masse des CD pour tester
     leur qualité

(***) cela peut s'aggraver en virtualisation lourde si l'OS virtualisé
      se voit présenter un flot de blocs virtuels désalignés

[1] https://github.com/torvalds/linux/blob/16fbf79b0f83bc752cee8589279f1ebfe57b3b6e/drivers/md/raid1.c#L2498
[2] https://en.wikipedia.org/wiki/Data_Integrity_Field