[gull] [Resolu en partie] Ext4 - forcer la reallocation des bad sectors

Thu Oct 10 13:04:39 CEST 2024

Hello Félix,
bonjour à tous,

> Le 10 oct. 2024 à 08:23, felix via gull <gull at forum.linux-gull.ch> a écrit :
> 
> Au rayon du ``je ne sais pas'': 8 pending sectors de 4096, cela
> fait 32Kb... Question de point de vue.
> Maintenant, si tu vois ce chiffre passer à 9 et non pas à 16, cela
> infirmera de fait ton hypothèse.

L'hypothèse est confirmée: il a suffit de forcer l'écriture du premier des 8 secteurs "pending", pour que la totalité des 8 secteurs disparaissent du rapport SMART, avant même d'avoir encore traité les 7 secteurs suivants. En fait, c'était bien un seul bloc physique de 4Ko sur le HDD qui était illisible, impactant donc d'un seul coup 8 secteurs logiques de 512 octets. Cette différence entre secteur logique de 512 octets, maintenu pour des raisons de compatibilité, et secteur physique de 4096 octets, sur les HDD modernes, est source de confusion.

Voilà la séquence, copiée partiellement à la main d'un screenshot, l'OCR n'est pas encore parfait:

# smartctl -A /dev/sda | grep -i sector

  5 Reallocated_Sector_Ct   0
197 Current_Pending_Sector  8

# hdparm --yes-i-know-what-i-am-doing --write-sector 102197032 / dev/sda

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

# smartctl -A /dev/sda | grep -i sector

  5 Reallocated_Sector_Ct   0
197 Current_Pending_Sector  0

Si on croit le rapport SMART, le firmware a choisi de ne pas ré-allouer le secteur défectueux (Reallocated_Sector_Ct reste à 0); il aura suffit de réécrire le secteur pour qu'il redevienne lisible. Jusqu'à quand ?

Un selftest long SMART n'a pas détecté d'autres bloc défectueux:

# smartctl -l selftest /dev/sda
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-122-generic] (local build)
Copyright (C) 2002-20, 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 offline    Completed without error       00%     40195         -
# 2  Extended offline    Completed: read failure       90%     40045         102197032
# 3  Short offline       Completed without error       00%      4729         -
# 4  Short offline       Completed without error       00%        23         -
1 of 1 failed self-tests are outdated by newer successful extended offline self-test # 1

C'est un log de systemd pesant 72Mo qui s'étend sur les 8 secteurs défectueux 102197032-102197039. Bon, le log est désormais oblitéré par des zéros sur un fragment de 4096 octets, mais ça n'aura sans doute jamais de conséquence. La chance.

Pour toutes ces manipulations bas niveaux, et notamment pour chercher la correspondance entre :
numéro de secteur sur le disque donné par le selftest SMART
   -> numéro de secteur sur la partition concernée
      -> numéro d'inode dans le système de fichiers ext4 de cette partition
         -> nom et chemin du fichier impacté

cette page de la documentation smartmontools est d'une aide inestimable:

https://www.smartmontools.org/wiki/BadBlockHowto#ext2ext3firstexample

> Du coup, je me retrouve avec un disque de 4 TB qui à pris un méchant
> coup, j'ai envie de voir ce que je peux en faire.
> - badblock -> il y a une pétée de dégats. répartis dans 3 zones
>   situées, de mémoire, à environ 1Tb, 2.5T et la dernière, je ne
>   sais plus...

Face à un HDD qui souffre de secteurs défectueux distribués à plusieurs endroits, avons-nous en open source un logiciel qui automatise l'identification des fichiers touchés par ces secteurs ? Par exemple qui sort un rapport sur:

 - la position de chaque secteur defecteux;
 - leur position dans les partitions concernées;
 - leur position dans les fichiers concernés;
 - l'inventaire et le chemin des fichiers concernés.

J'ai souvent vu des outils de "récupération", qui font le maximum pour retrouver des données fragmentées dans un système de fichiers partiellement corrompu. J'ai du passer à coté des outils qui facilitent l'inventaire des fichiers touchés par des secteurs défectueux sur le HDD. Si vous avez des recommandations ?

> 1. sauvegarde valeurs SMART smart-1.txt
> 2. badblock > bblist4mkfs.bb (pour mkfs.ext, voire docs!)
> 3. sauvegarde valeurs SMART smart-2.txt -> diff
> 4. mkfs avec le fichier bblist4mkfs.bb
> 5. check smartctl -x | diff smart-2.txt -

L'étape 4, ça veut dire que le système de fichier se formate autour des secteurs défectueux, sans les réécrire, mais en les évitant ?

> Le moyen serait d'utiliser un snapshot:
> 1) passer en single-user mode
> 2) démonter tous, `remount -o remount,ro /`
>    A partir de là, c'est chiant si on se plante, 'faut recommencer
>    à zéro et les .history ne conservent rien! ;-b
> 3) prévoir un stockage alternatif, cela peut être un stockage USB,
>    disque externe ou de la RAM (ramdisk ou quelque chose comme
>    `dd of=/dev/shm/ram.raw count=0 seek=4194304` pour un tampon
>    de 2Gb
>    (A noter que pour utiliser un tampon plus gros, vous risquez
>    de devoir recourir à une commande comme:
>     mount -o remount,dev,size=22G /dev/shm
>    et bon, 'faut avoir suffisament de RAM ;-)
> 4) snapshot, via dmsetup:
>     losetup -f /dev/shm/ram.raw   # pas nécessaire si RAMDISK
>     disk=sda
>     totsize=$(blockdev --getsz /dev/$disk)
>     dmsetup create origin <<<"0 $totsize snapshot-origin /dev/$disk"
>     dmsetup create snap <<<"0 $totsize snapshot /dev/mapper/origin /dev/loop0 N 8"
>     Ref: https://wiki.gentoo.org/wiki/Device-mapper
> 
> A partir de là, tu peux utiliser /dev/mapper/snap en RW, à concurrence
> de 2Gb (ou plus, selon point 3). Des outils comme fsck pour fonctionner
> sans se heurter à des problèmes de disques
> 
> Tu dois pouvoir ensuite pouvoir monter ce disque (en lecture seule) et
> récupérer tes fichier (sur un support externe ou via SSH:
>   ssh root at headless /bin/sh <<<'tar -cplC /mnt . | zstd' |
>       zstdcat | tar -xpC /media/$USER/myLocalUsbStorage
> ;-)

C'est du cousu main d'expert, je vais regarder ça avec soin. Sans accès physique au serveur, pour le point 3), un stockage sshfs sera-t-il suffisamment stable pour écrire un snapshot de plusieurs giga ?

--
Frédéric Dumas
f.dumas at ellis.siteparc.fr