[TUTO] Préparation des disques avec Badblocks

[apossium]

@lucas3d merci pour ce retour.

Peux tu confirmer les réglages (pattern) utilisés ?

NAS (modèle et version DSM), quantité ram interne, commande ?

--

Pour ma part, je viens de lancer un badblocks depuis un live DVD de CentOS avec seulement 2 Go de ram … sur 2 disques de 8 To en même temps.

 

[lucas3d]

Il y a 4 heures, apossium a dit :

Peux tu confirmer les réglages (pattern) utilisés ?
NAS (modèle et version DSM), quantité ram interne, commande ?

Je l'ai fait sur mon Synology directement, un DS918+ avec 4 Go de ram.

badblocks -nvs /dev/sdd > /volume1/sdd.log 2>&1 &

Par conte, le test avec mes WD green 2 To est beaucoup plus lent (25% en 100 heures!)...

 

[apossium]

Il y a 19 heures, lucas3d a dit :

Je l'ai fait sur mon Synology directement, un DS918+ avec 4 Go de ram.

badblocks -nvs /dev/sdd > /volume1/sdd.log 2>&1 &

Par conte, le test avec mes WD green 2 To est beaucoup plus lent (25% en 100 heures!)...

 

OK merci, c'est une vérification dite non destructive et simple passe (paramètre -n), adapté par ex. aux opérations de maintenance préventive.

De faite c'est 4 fois plus rapide qu'avec le paramètre -w qui lui comporte 4 passes … lui plus adapté au vérif. de nouveaux disques.

Citation

Default is an extensive test with four passes using four different patterns: 0xaa (10101010), 0x55 (01010101), 0xff (11111111) and 0x00 (00000000)

Donc attention, la vérification que tu as réalisée est pertinente mais reste moins profonde (je ne discute pas le choix).

8 To c'est long, je suis en train d'en faire l'expérience :(

 

 

 

[Einsteinium]

Le test non destructif est plus que suffisant et bien meilleur que tous les test constructeurs... là tu fatigues juste tes disques pour rien... et tu leurs crament 4 cycles d’écritures pour rien...

[apossium]

non, je ne suis pas d'accord.

La vérif. non destructive ne vérifie pas avec certitude chaque bit …

Dans le cas du test destructif, on a 2 changements d'état (4 x écritures + 4 x lectures ) obligatoires.

Dans le cas du test non destructif, si je comprends bien puisque c'est un pattern aléatoire …

un bit peut être à 0, écrit à 0, puis remis à 0. Donc on ne sait pas si il peut être écrit …

Ceci dit chacun fait ce qu'il veut …

Les disques qui sont intégrés en prod. doivent être vérifiés de mon côté, cela pose trop de problème si aller retour.

Si il existe une manière moins contraignante de vérifier je suis preneur (augmentation taille mémoire, arrêt après phase 3 par ex. = 1 changement état garanti).

Mais la cet essai non destructif ne me satisfait/convient pas (tel que je le comprends).

 

Modifié le 7 novembre 2017 par apossium

[Einsteinium]

Mouaip... va refaire un tour dans les docs de badblock, tu perdras moins de temps la prochaine fois que tu préparas un disque 

[apossium]

@Einsteinium : tout ce que je dis / affirme se repose sur des info. disponibles ici : https://wiki.archlinux.org/index.php/badblocks

Maintenant je veux bien apprendre / comprendre. Me renvoyer vers des lectures sans indications, j'accepte volontiers un lien ou deux,

parce que ce sont mes recherches précédentes qui me permettent de prendre cette position pour les 4 pattern.

nota : surtout si je passe 8 jours à vérifier un disque alors que cela ne sert strictement à rien …

Modifié le 8 novembre 2017 par apossium

[Fenrir]

@Einsteinium et @apossium : vous avez tous les 2 raison, ne vous fâchez pas

• -n va effectivement moins loin que -w mais convient à la plupart des cas
  • il est possible que sur la durée de vie du disque certain blocs en erreurs provoquent des problèmes
  • mais il est aussi possible de cramer des données pendant le test
  • => attention aux sauvegardes
• pour une machine sur laquelle on peut difficilement intervenir, le -w peut s'avérer utile mais il fatigue aussi nettement plus les disques
  • c'est 16 cycles qui sont effectués (4x4)
  • et la réserve de blocs sera nettement plus entamée (y compris pour des blocs qui n'auraient jamais été utilisés)
  • =>il y aura moins de temps entre le début des problème et la mort du disque => il faudra plus superviser ces disques

C'est donc une question de besoins avant tout

ps : le facteur temps peut aussi rentrer en ligne de compte

[apossium]

@Fenrir : merci pour ces précisions.

L'objectif ici est de valider des disques durs neufs avant mise en production dans un serveur (et tenter de garantir un fonctionnement même si c'est prétentieux).

Si des secteurs défectueux sont observés (en nombre important) sur un disque neuf (le but principal de l'opération).

nota : je ne sais pas définir "important" si vous avez des info. …

Ce disque ne sera pas utilisé (disque réparé ou non).

---

Par ailleurs, je ne mesure / saisi pas la logique de la fatigue disque évoquée …

Si un disque neuf ne supporte pas 4 pattern alors qu'il est neuf, que va t il dire ou faire quand il sera en prod. ? j'ai pas envie de travailler ? :D

Combien de cycle peut encaisser un même secteur/bloc en R/W ? A part les facteurs MTBF, AFR, Wear ou load/unload cycle, je n'ai pas trouvé d'info la dessus …

Après recherches, les info concernant les HDD ne sont plus mis en avant (le SSD a tout remplacé chez Google :D). Pas simple, l'utilisation du paramètre - est requis :(

--

Le paramètre -c augmente l'efficacité de badblocks. De quelle ordre de grandeur … essai à faire … mais pas avec mes 8 To :D

 

[Fenrir]

il y a 1 minute, apossium a dit :

nota : je ne sais pas définir "important" si vous avez des info. …

C'est une question de moyen VS importance des données. Pour ma part :

• 1 bloc en erreur (non corrigé) => remplacement du disque programmé asap
• réallocation sur 2 chiffres => idem

il y a 4 minutes, apossium a dit :

Si un disque neuf ne supporte pas 4 pattern alors qu'il est neuf, que va t il dire ou faire quand il sera en prod. ? j'ai pas envie de travailler ? :D

Ce n'est pas tant les 16 cycles que l'endroit où ils sont fait qui peut poser problème.

En usage "normal", on n'écrit JAMAIS sur toute la surface d'un disque, ce qui laisse plein de place pour la réallocation des blocs/secteurs défectueux par le "système" lors des phases de scrubbing (en plus de la réallocation gérée par le disque lui même) et diminue d'autant les chances de tomber sur un problème.

En faisant un test destructif, toute la surface du disque y passe et le nombre de réallocation (gérée par le disque, pas par le système) peut très vite augmenter pour corriger des erreurs sur des zones où tu n'aurais de toute manière jamais écrit.

En passant, -w implique qu'il n'y a rien sur le disque (même pas DSM dans le cas d'un syno), donc ce n'est pas toujours possible de s'en servir.

il y a 23 minutes, apossium a dit :

Combien de cycle peut encaisser un même secteur/bloc en R/W ?

Plus que la durée de vie de la mécanique du disque ne le permet.

-----

Et pour le -c, ça peut augmenter la vitesse, la réduire mais aussi augmenter ou réduire la fiabilité du test => si tu veux jouer avec cette option il va falloir connaitre précisément toutes les spécifications de ton disque (taille des blocs, tampon, blocs par cylindre, nombre de plateau, ...) et sortir la règle à calcul. Par défaut c'est 64 blocs en parallèle avec 1024B/bloc (ton lien date de 2002, il n'est plus du tout adapté). Sur les disques actuels, un bloc c'est généralement 4096B (c'est le -b dans les options)

[apossium]

@Fenrir : merci pour ton temps, je comprends mieux la logique …

Un des facteurs à surveiller serait donc la taille du disque adressable (puisque si elle diminue c'est que le firmware alloué / déplacé / invalidé des secteurs.

Je comprends aussi qu'un disque ne peut être parfait même si après les tests on obtient zero erreurs.

Il y a des mécanismes sous-jacents automatique que l'on ne maitrise pas …

Merci encore à vous deux !

[Fenrir]

Il y a 10 heures, apossium a dit :

Un des facteurs à surveiller serait donc la taille du disque adressable (puisque si elle diminue c'est que le firmware système alloué / déplacé / invalidé des secteurs.

Si c'est le firmware qui le fait il pioche dans sa réserve perso (qui n'est pas visible), mais dans dans tous les cas on parle ici que blocs, donc les variations sont minuscules.

[firlin]

Je veux pas paraitre impertinent mais la on dérive du tutos original Messieurs

Le plus simple c'est d’ouvrir un nouveau post, pour parler des caractéristique de badblock

 

[apossium]

il y a 47 minutes, Fenrir a dit :

Si c'est le firmware qui le fait il pioche dans sa réserve perso (qui n'est pas visible), mais dans dans tous les cas on parle ici que blocs, donc les variations sont minuscules.

Je ne reproche rien à ce mécanisme (et vu ce que représente un bloc ie. 4096 bit).

Je dis simplement que le nombre de bloc adressable ce serait un moyen indirect de vérifier le nombre de bloc défectueux et l'évolution de la panne.

Peut être que SMART les enregistre d'ailleurs ? Ceci dit si on enregistre/filme puis compare la valeur du nombre de blocs adressables (depuis début puis périodiquement).

On peut constater une dégradation.

--

Je viens enfin d'intégrer vos remarques …

En écrivant des 0 et 1 sur un bloc de manière aléatoire, si une partie du secteur est défectueuse, il y aura certainement plus d'un "bit" concerné dans le lot de 4096 …

et donc on ne passe pas vraiment à côté d'un "zone défectueuse" (je suppose que ce sont des zones défectueuse et non un bit seul) en écrivant de l'aléatoire …

Alors que dans le cas de l'écriture avec 4 pattern (forcer l'écriture à plusieurs reprises), on détecte les moindres défauts.

C'est ce que tt le monde a évoqué (pas suffisamment explicite par écrit certes) … avec le recul, je comprends mieux … désolé !

Et puis j'ai lu qu'il y a une somme de contrôle après chaque bloc donc si il a été mal écrit, le bloc est invalidé à la première relecture je pense.

---

Oui si vous voulez spliter pas de pb. Mais cela concerne quand même badblocks (on du moins un disque) et son fonctionnement.

Ces échanges sont pertinents ! Et puis on a presque fini :D

Merci encore.

 

 

[firlin]

Si on veut @apossium sauf que cela risque de perturber le personne qui n'ont pas un niveau très élever dans ces choses là.

En clair @Fenrir te faut une explication de texte sur cette fonction.

[apossium]

Bonjour,

voici un rapide retour d'un essai :

sur un disque 8 To WD Red, essai non destructif (sur un banc d'essai CentOS last, disque interne SATA) :

sudo badblocks -nsv -b 4096 -c 5000 /dev/sdb > /home/liveuser/Desktop/sdb.log 2<&1

67:25:15 elapsed. (0/0/0 errors)100.00% done, 67:25:16 elapsed. (0/0/0 errors)done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

[Diabolomagic]

Bonsoir, tout d'abord merci pour ce tuto qui est dés plus utile quand on débute.

Je posséde un DS416Play avec ces 1Go de Ram, pensez vous que je peux lancer la vérification des 4 disques dur (4X 4To WD RED) en même temps ou la configuration matériel risquerait de ne pas suivre ?

 

[firlin]

Bonsoir @Diabolomagic

Tu ne peux en lancer que trois en même temps car il te faut un disque avec le DSM installer dessus et fonctionnel.

Oui cela ne pose pas de problème.

Ps: passe par la case présentation certain sur le forum y sont sensible.

 

[Diabolomagic]

il y a 11 minutes, firlin a dit :

Bonsoir @Diabolomagic

Tu ne peux en lancer que trois en même temps car il te faut un disque avec le DSM installer dessus et fonctionnel.

Oui cela ne pose pas de problème.

Ps: passe par la case présentation certain sur le forum y sont sensible.

 

Ah mince, alors comment tester le disque dur qui va contenir le DSM (sans passer par le PC) ?

(le PC est dans la chambre et j'en connais une qui serai pas ravi que je lui annonce qu'il faut laisser tourner le PC toute la nuit car le test du DD n'est pas terminé...)

 

P.S : No problem, je passe par la case présentation dés demain :)

Modifié le 30 novembre 2017 par Diabolomagic

[firlin]

Le 17/09/2017 à 12:36, firlin a dit :

Variante pour déclare le disque « fail »

il la variante c'est expliqué

[jlnmrt]

Bonsoir à tous,

J'ai voulu suivre le tuto pour 1 HDD de 4To (WD40EZRZ) :
- dsm installé sur un autre disque avec 1 volume,
- le HDD de 4To inséré dans le DS418play
- service SSH activé,
- tache créée et exécutée avec le script : badblocks -nvs /dev/sdb > /volume1/toto/sdb.log 2>&1 &
- connecté au nas via winscp

Via winscp, je ne vois pas de sous répertoire "toto" dans l'arborescence du répertoire "volume1". Alors j'ai essayé de le créer mais j'ai le message d'erreur :
mkdir: cannot create directory 'toto': Permission denied
Je ne sais pas vérifier si j'ai les droits en écriture ni si badblock est déjà lancé ...

Je taquine la limite de mes compétences informatiques depuis plusieurs jours maintenant, alors je viens cherche un peu d'aide !

 

[firlin]

@jlnmrt tu peux crée le répertoire avec putty en ligne de commande. (c'est la 2eme méthode mais tu stoppes après le sudo -i , voir avant ).

Sinon essai en ligne de commande avec Putty c'est la partie après la variante.

[jlnmrt]

Bonne année à tous,

Pour moi cela commence par une bonne nouvelle ; j'ai pu lancer le badblock sur mes disques (le 1er terminé en un peu moins de 34H et n'a trouvé aucun bad block, le test des 3 autres simultanément est en cours).

Pour le 1er, j'ai lancé badblock avec putty et la commande " badblocks -nvs /dev/sdX > /volume1/sdX.log 2>&1 &" (donc sans nom de répertoire générique "toto").

Pour les trois autres j'ai pu le faire directement via une tâche du NAS toujours sans créer un nouveau répertoire "toto".

 

 

[BakaNeko57]

Bonjour, meilleurs voeux à tous,

Je me lance enfin dans la préparation de mon disque neuf de retour de RMA (je ne l'avais pas fait sur mes disques à la base, ne sachant pas qu'il était conseillé de le faire).

J'ai créé mon script, j'ai créé mon répertoire où mon log d’exécution doit apparaître.

Je lance mon script dans le planificateur, presque instantanément je reçois un mail disant:

"Cher utilisateur,

Le planificateur de tâches à terminé une tâche planifiée.

Tâche : Badblocks disque baie 1

Heure de début : Wed, 03 Jan 2018 00:01:54 GMT Heure d’arrêt : Wed, 03 Jan 2018 00:01:54 GMT État actuel : 0 Sortie standard/erreur :

Sincères salutations,

Synology DiskStation"

Mon script était le suivant: badblocks -nvs /dev/sda > /volume1/Maintenance NAS/Badblocks/Disk 1/sda.log 2>&1 &

Quand je me rends dans le chemin d'accès avec winscp pour ouvrir mon log, le dossier est vide.

 Je crois bien que j'ai du louper quelque-chose...

Nota: manip effectuée sur un DS416Play à jour, baie 1 avec disque RED 4To de retour de RMA, aucune manip effectuée sur le disque à part l'insertion dans le NAS. Baie 2 occupée par le même disque avec toutes mes données + DSM à jour.

Je n'ai pas installé de package contenant badblocks (le tuto n'en parle pas, je l'avais lu sur un autre thread, mais vu que ça n'est pas mentionné dans le tuto j'ai supposé que c'était obsolète depuis, donc je suppose qu'il est désormais intégré d'office dans DSM).

Merci d'avance pour vos retours.

[firlin]

Bonjour BakaNeko57,

Si tu veux tester le disques 1 donc c'est bien sda ; par contre tu es sur que ton disques dans la baie n°2 c'est le volume 1 ?

Ensuite fait plus court pour le répertoire du log : là tu es sur le volume avec 1 répertoire et 2 sous répertoire.

Je te propose de mettre ça : /volume1/Maintenance/sda.log 2>&1 &

Vérifie que tu as bien le droit en écriture dans le répertoire aussi