[gull] Confiance ou pas dans vos disques (was: Ext4 - forcer la reallocation des bad sectors)
Marc SCHAEFER
schaefer at alphanet.ch
Thu Oct 10 13:35:27 CEST 2024
Salut,
On Thu, Oct 10, 2024 at 08:23:37AM +0200, felix via gull wrote:
> > Ç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)!
Il y a bien longtemps, disons plus de 30 ans, le SCSI disposait de pages
de mode où l'on pouvait configurer énormément de choses (durée et nombre
de réessais de lecture physique, utilisation ou non de la correction
d'erreur, réécriture sous quelles conditions, etc). [1]
A l'époque, nul besoin de segmenter le marché en:
- disque optimisé NAS
- disque "pro"
- disque optimisé stockage et rejeu de vidéo (== pas trop
de réessai, pas de réécriture)
Tout cela se faisait par configuration.
Et la même chose pour les lecteurs de cassettes DAT/DDS de l'époque.
Entre temps, l'IDE (horreur absolue, même pas de parité durant le
transport!), puis le SATA (pas très performant
au début, heureusement que le command-queueing SCSI est apparu sous
forme de NCQ, avec des bugs terribles au début) sont arrivés.
On retrouve encore aujourd'hui, en partie, ces configurations en SAS ou
en SATA ou USB (UAE): le protocole haut-niveau SCSI est un peu
devenu la lingua franca du stockage (avec restrictions).
Là dernière fois que j'avais joué avec ça, c'était pour relire des DVDs
de sauvegarde *en désactivant toute correction d'erreur* (et ainsi voir
s'il y avait des problèmes potentiels). Mais entre temps je n'ai plus
trop joué avec ça: enfin si, en SAS, je viens de retrouver l'amusement
des MODE PAGES pour un lecteur LTO (ben oui, là aussi le recovery ça se
configure, et on peut consulter les compteurs pour qualifier une
cassette, par exemple: regarde combien de ré-essais il y a eu en
écriture, regarder combien de correction d'erreur à la lecture).
Maintenant, aujourd'hui j'ai tendance à faire moyennement confiance aux
disques, donc j'ajoute une couche d'intégrité logicielle Linux [2]. En
particulier en RAID > 0, en cas de détection de corruption par ce
système alors que le disque-dur n'aurait rien vu (ou aurait perdu
le bloc), on ne devrait rien perdre et réécrire les secteurs perdus:
j'ai fait quelques tests de corruption à la main.
Enfin, on peut aller plus loin et faire calculer des CRC par l'OS
et *les stocker après le bloc du disque-dur*. On peut alors
vérifier de bout en bout sans gaspiller de la place. C'est le
mode T10 SCSI. Ou on peut reformatter (bas niveau) et utiliser
même des hachages. Voir aussi [2].
[1] https://en.wikipedia.org/wiki/SCSI_mode_page
[2] https://wiki.alphanet.ch/Sandbox/ExperienceIntegriteFS
More information about the gull
mailing list