[Tuto] Tester un gros disque (> 14 To) sans badblocks : Couche de chiffrement et écriture de zéros

  • Vague de SPAM

    Suite à une vague de spam sur le forum, les inscriptions sont temporairement limitées.

    Après votre inscription, un membre de l'équipe devra valider votre compte avant qu'il ne soit activé. Nous sommes désolés pour la gêne occasionnée et vous remercions de votre patience.

MilesTEG

Administrateur
Membre du personnel
6 Septembre 2020
3 921
930
313

Tester un très gros disque > 14To quand badblocks ne peut plus gérer​

Méthode de la couche de chiffrement + Écriture de 0 chiffrés​

[B][COLOR=rgb(184, 49, 47)]Version : 2026-01-10[/COLOR][/B]

J'ai été confronté à un problème pour utiliser la commande badblocks pour tester un disque dur de grande capacité (ici 18 To) ...
badblocks est un binaire 32 bits, qui ne gère dont pas les grosses capacités...
Vous aurez ce message :
Code:
/sbin/badblocks: Value too large for defined data type invalid end block (4394582016): must be 32-bit value

Voici quelques explications issues de ChatGPT (à prendre avec des pincettes bien entendu, mais je pense que c'est valide) :

Pourquoi badblocks ne fonctionne pas “normalement” sur >14 To

  • badblocks a été conçu pour des disquettes et petits disques → il utilise des index 32 bits.
  • Sur un disque de 18 To avec des blocs de 4 K, le nombre de blocs dépasse 4 milliards, ce qui dépasse la limite de l’outil.


Pourquoi segmenter le test ou augmenter -b ne résout rien

  • Segmenter le disque : casse la cohérence des passes (écriture + lecture) → certains défauts peuvent ne jamais être détectés.
  • Augmenter la taille de bloc -b : réduit le nombre de blocs mais perd la précision (un seul secteur défectueux rend tout le bloc suspect) et n’aide pas le disque à travailler en blocs physiques 4 K.


Méthodes modernes recommandées pour gros disques

  1. Écriture complète sécurisée : via shred ou un chiffrement AES-plain pour remplir le disque.
  2. Vérification : lecture complète avec cmp /dev/zero ou tests SMART étendus (smartctl -t long).
  3. Surveillance continue : suivre SMART pour détecter les secteurs défectueux pendant l’utilisation.


✅ En résumé :

badblocks n’est plus adapté aux disques modernes de grande capacité. Les méthodes modernes (écriture complète + lecture + SMART) sont plus fiables, plus rapides et sûres.

Donc, voici une nouvelle méthode pour tester son disque haute capacité (supérieure à 14To) (source : https://wiki.archlinux.org/title/Badblocks#Alternatives ).
On va créer une couche chiffrée sur tout le disque, puis on va écrire des zéros dessus, et enfin on refera un test smart étendu.
Cela créera un stress test sur tout le disque : l’écriture complète va réinitialiser/isoler les secteurs connus comme défectueux. Et le smart étendu final vérifiera qu’aucune nouvelle erreur n’est présente et que le disque “remonte” sain.

Bash:
# Se placer en root
sudo -i

# 1️⃣ Lancer une session tmux
tmux new -s test_sata1

# 2️⃣ Créer un dossier pour recueillir un fichier log
mkdir -p /volume1/Scripts-NAS/z_tests_disk_18To

# 3️⃣ Création de la couche chiffrée sur le disque (⚠️ Attention, ça va effacer tout le disque, les données présentes seront irrémédiablement effacées ⚠️)
cryptsetup open /dev/sata1 sata1_test \
  --type plain \
  --cipher aes-xts-plain64 \
  --key-size 512 \
  --key-file /dev/urandom

# 4️⃣Vérification de la création
ls -lh /dev/mapper/sata1_test

# 5️⃣ Remplissage de la couche chiffrée, désormais ouverte, avec des zéros, qui s’écrivent sous forme de données chiffrées
shred -v -n 0 -z /dev/mapper/sata1_test 2>&1 | tee /volume1/Scripts-NAS/z_tests_disk_18To/shred_sata1.log

# 6️⃣ Lecture + comparaison complète
#      S'il n'y a pas d'erreur, aucune sortie, et rien dans le log sauf ceci à la toute fin : cmp: EOF on /dev/mapper/sata1_test
#      S'il y a des erreurs, le test sera interrompu immédiatement.
set -o pipefail; cmp -b /dev/zero /dev/mapper/sata1_test 2>&1 | tee /volume1/Scripts-NAS/z_tests_disk_18To/cmp_sata1.log && echo "✅ CMP OK : aucune erreur détectée" || echo "❌ CMP ÉCHEC : différences détectées (voir le log)"

# 7️⃣ Faire un test smart étendu (il est possible de le lancer depuis DSM)
smartctl7 -t long /dev/sata1

# 8️⃣ Fermeture de la couche de chiffrement
cryptsetup close sata1_test

##########################

# 9️⃣ Vérifier les données smart
smartctl7 -a /dev/sata1 2>&1 > /volume1/Scripts-NAS/z_tests_disk_18To/smart_sata1_after.log

# 🔟 Terminer la session tmux
exit


Bash:
# Tant que le shred n'est pas terminé, ne pas faire de CTRL+C
# On peut sortir de la session tmux avec Ctrl + B puis D (on détache la session)
# Pour lister les session tmux :
tmux ls

# Pour revenir dans une session tmux :
tmux attach -t test_sata1

# Vérifier l'état d'avancement du shred :
tail -f /volume1/Scripts-NAS/z_tests_disk_18To/shred_sata1.log





Notes de changements

  • 2026-01-10 (2) : modification de la commande CMP pour affiche plus clairement si le test est validé, ou en échec.
  • 2026-01-10 : ajout du message d’erreur de badblocks sur un HDD de grosse capacité
  • 2026-01-09 : Version initiale
 
Dernière édition:
  • J'aime
Réactions: gva et Frank-Pomme
2026-01-10 : ajout du message d’erreur de badblocks sur un HDD de grosse capacité

2026-01-10 (2) : modification de la commande CMP pour affiche plus clairement si le test est validé, ou en échec.
 
Dernière édition: