[gull] Ext4 - forcer la reallocation des bad sectors
felix
felix at f-hauri.ch
Thu Oct 10 08:23:37 CEST 2024
Le Wed, Oct 09, 2024 at 04:13:47PM +0200, Frederic Dumas via gull a écrit :
>
> Dans un cas un peu différent sur un HDD physique, quand le rapport
> SMART affiche des Current_Pending_Sector, mais encore zéro
> Reallocated_Sector, les outils ext4 donnent-ils la possibilité de
> forcer une écriture sur ces secteurs douteux ?
Pas franchement.
D'une manière générale, j'ai du mal à faire confiance dans un stockage
de données (tant que je ne peux pas voir avec mes yeux que mes données
sont là, je dois faire confiance au disque!) Heureusement SMART aide
un peu. Dès lors, quand un disque commence à incrémenter l'un des
compteurs
5 Reallocated_Sector_Ct -O--CK 100 100 050 - 1
197 Current_Pending_Sector -O--CK 100 100 050 - 1
198 Offline_Uncorrectable -O--CK 100 100 050 - 0
199 UDMA_CRC_Error_Count -O--CK 100 100 050 - 0
je ne fais plus confiance du tout.
( A noter que le compteur
1 Raw_Read_Error_Rate -O--CK 100 100 050 - 0
peut afficher des valeurs élevées selon le constructeur, cela
ne veut pas forcément dire grand'chose.)
Pour l'expérience, je me suis permi d'utiliser pour mon usage
perso, un disque de 3Tb qui affichait des erreurs SMART en
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 -
Constaté des diffs entre smart-1 et smart-2, mais plus après...
J'ai alors assigné ce disque pour des backup, pendant plusieurs années!
Je n'ai jamais reproduit cette expérience pour un client.
> Ça me parait un bon moyen de les faire ré-allouer sans plus attendre
> par le firmware du HDD.
C'est son boulot, (au firmware du HDD)! Ne sachant pas précicement
ce que le constructeur à prévu sur son controlleur, je ne sais pas
non plus ce que veut dire ``Reallocated sector'' précisement. J'ai
une idée de la construction des ``cylindres'' et ``secteurs'', mais
juste une idée. Le reste est obscur et propriété du constructeur du
disque. Par conséquent, je vois mal comment ``faire mieux''.
> Le jeu est évidement de trouver les fichiers effectivement corrodés
> par les bad sectors.
>
> https://wiki.archlinux.org/title/Identify_damaged_files
>
> Malheureusement, le tuto exige de travailler sur une partition
> non-montée, ce qui m'est impossible. Il s'agit ici d'un serveur
> headless hébergé, accessible à distance en ssh, dépourvu d'interface
> de management dédiée, dépourvu de RAID, et sur lequel l'unique HDD
> commence doucement à cultiver huit premiers Current_Pending_Sector.
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
;-)
> Si ceux qui aiment le bas niveau ont une posologie douce, adaptée à
> ext4 et à ce cas de figure pas critique... d'avance merci !
``posologie douce'', désolé! Il s'agit plus d'un chantier d'envergure!
> Au passage, comme nos HDD modernes fonctionnent tous avec des secteurs
> physiques de 4096 octets, mais continuent à présenter à l'OS des
> secteurs logiques de 512 octets, ai-je raison de penser que
> Current_Pending_Sector = 8 veut dire en réalité qu'un seul bloc de
> 4096 octets est potentiellement illisible, ce qui se traduit dans le
> rapport SMART par 8 secteurs logiques (8 x 512 octets contigus) ?
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.
--
Félix Hauri - <felix at f-hauri.ch> - http://www.f-hauri.ch
More information about the gull
mailing list