[TUTO] Préparation des disques avec Badblocks

[Thierry94]

Un petit retour pour vous dire que la méthode rapide de Firlin marche bien !
Sur mon 718+ avec 8GO de ram, 10h00 pour le 1er disque WD RED 6 TO,  le 2ème tourne depuis ce matin

[arnlig3550]

Il y a 18 heures, firlin a dit :

Remarques :

      Pour ceux qui veulent accéléré le processus vous pouvez taper cette commande à la place de celle du dessus (c'est recommander pour les disques Seagate ).

      badblocks -nvs -c 98304 /dev/sdX > /volume1/toto/sdX.log 2>&1 &

Ca marche aussi sur les disques WD ?

[firlin]

Oui @arnlig3550

[arnlig3550]

Il y a 22 heures, Zeus a dit :

Il te faut simplement localiser en SSH le processus de Badblock via la commande :

htop

Ensuite, tu kill le processus en question :

kill PID (PID qui est l'ID du processus).

Tu peux éventuellement arrêter un processus par son nom si tu le connais via la commande :

pkill nom_du_processus

 

Etant dans le même cas que @Thierry94, j'ai voulu stopper le badblocks en cours de mon 1er disque (54% en 53 heures et j'ai un deuxième disque à suivre aussi !) pour refaire avec la commande plus rapide, mais quand je veux stopper le processus en cours, j'ai un message me disant que c'est pas possible...

As tu une idée @Zeus ?

Merci

[Thierry94]

Je dirais qu'il faut etre en root donc sudo -i avant de passer la commnde kill

[firlin]

Oui il faut être en root pour tuer le processus
Pourquoi Htop n'affiche rien tu as cache les résultat

 

[unPixel]

Quand tu fais CTRL+C pour sortir de htop, ça ferme le programme htop donc rien de visible. Elle est normale sa capture d'écran 😉

 

Modifié le 2 février 2019 par Zeus

[arnlig3550]

Oui htop se ferme sauf que moi j'ai fais F10 pour quitter, mais ça marche peut-être aussi en faisant CTRL+C (ou parce que je suis avec Kitty et non Putty)

[arnlig3550]

Ah c'est beaucoup mieux avec ce code ! T'aurais pu le dire plus vite @firlin 😊😁

1% en 4:35min contre 1% en 1h avant ! 😁

Modifié le 2 février 2019 par arnlig3550

[unPixel]

il y a 19 minutes, arnlig3550 a dit :

Oui htop se ferme sauf que moi j'ai fais F10 pour quitter, mais ça marche peut-être aussi en faisant CTRL+C (ou parce que je suis avec Kitty et non Putty)

C'est surtout que c'est LE raccourcis clavier pour quitter un programme dans un terminal...🙄

[arnlig3550]

F10 c'est pourtant plus rapide à faire 😁

[unPixel]

De mon côté sous Windows 10, F10 créer un signe tilde dans mon terminal.

[arnlig3550]

voilà ce que j'avais approximativement quand j'ai fais htop (c'est une impression écran prise sur internet, pas la mienne), en bas à droite c'est mit F10 > QUIT

Je suis sous windows 7

[unPixel]

En effet, je n'avais jamais fait gaffe à ce raccourcis car j'ai l'habitude de fermer un programme dans le terminal par le raccourcis clavier reconnu pour cette fonction à savoir CTRL+C qui fonctionne aussi pour htop.

Autant pour moi 😉

 

[arnlig3550]

Pas de soucis ! 😉

De mon coté je ne connaissais pas CTRL+C (mis à part pour "Copier" mais c'est tout).

On se couchera tous les 2 moins bêtes ! 😁

Modifié le 2 février 2019 par arnlig3550

[unPixel]

On ne copie pas avec CTRL+C sur un terminal 😜

[arnlig3550]

Non hors terminal 😁

Je me sers très rarement d'un terminal !

[unPixel]

Ok.

[Norm]

Bonjour,

Je viens de terminer à l’instant le test Badblocks pour mon DS918+ avec 4 Go de ram qui peut contenir 4 disques durs.

J’ai fait tous ces tests grâce au super Tuto de @firlin que je le remercie profondément.

Vu que je travaille sur un MacBook Pro, je n’ai pas eu besoin de Wincp ou de Putty. J’ai commencé par faire le premier test dans l’interface du NAS, mais par la suite, je n’ai travaillé qu’avec SSH.

Présentement, j’ai 2 disques WD60EFRX-68MYMN1 de 6To, configurés en SHR avec la protection de données sur un disque. Par contre, je viens de m’acheter 2 autres disques neufs de 6 To, soit 2 WD60EFRX-68L0BN1.

J’ai commencé mes tests sur ces 2 disques, que j’ai insérés dans les fentes 3 & 4, qui vont correspondre dans badblocks comme disque C et D.

Tous les tests ont été exécutés avec l’option -C 98304, ce qui augmente la rapidité considérablement.

J’ai fait ces tests avec ces lignes de commande :

 

badblocks -nvs -c 98304 /dev/sdc > /volume1/toto/sdc.log 2>&1 &

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

 

Ce test a pris environ 10 heures. Il a pris environ 4% de CPU et environ 33% de RAM.

 

Pour suivre l’évolution dans SSH, j’ai tapé cette commande.

 

tail -f /volume1/toto/sdc.log

tail -f /volume1/toto/sdd.log

 

Le second test a été fait sur le disque 2, soit B. Ce disque (ainsi que le disque 1) contient mes données. J’ai suivi la procédure de firlin (variante pour déclarer le disque fail ), soit :

 

mdadm /dev/md0 --fail /dev/sdb1

mdadm /dev/md0 --remove /dev/sdb1

mdadm --zero-superblock /dev/sdb1

mdadm /dev/md1 --fail /dev/sdb1

mdadm /dev/md1 --remove /dev/sdb1

mdadm --zero-superblock /dev/sdb1

mdadm /dev/md2 --fail /dev/sdb1

mdadm /dev/md2 --remove /dev/sdb1

mdadm --zero-superblock /dev/sdb1

 

Ensuite, j’ai tapé le code.

 

badblocks -nvs -c 98304 /dev/sdb > /volume1/toto/sdb.log 2>&1 &

 

J’ai eu le message “/dev/sdb is apparently in use by the system; it's not safe to run badblocks!” , alors j’ai tapé le code

 

badblocks -nvsf -c 98304 /dev/sdb > /volume1/toto/sdb.log 2>&1 &

 

Là, cela a fonctionné.

Pour suivre l’évolution dans SSH, j’ai tapé cette commande.

 

tail -f /volume1/toto/sdb.log

 

Ce test a pris environ 11 heures et 13 minutes. Il a pris environ 3% de CPU et environ 26% de RAM.

Quand ce test a été terminé, j’ai redémarré le NAS et je suis allé dans le gestionnaire de stockage \volumes \ réparer. Le système est revenu dans un mode normal.

 

Maintenant, il me reste à faire le test sur le disque 1, soit le A. Je n’ai pas modifier l’ordre physique des disques dans le NAS.

J’ai suivi la même procédure que précédemment, soit.

 

mdadm /dev/md0 --fail /dev/sda1

mdadm /dev/md0 --remove /dev/sda1

mdadm --zero-superblock /dev/sda1

mdadm /dev/md1 --fail /dev/sda1

mdadm /dev/md1 --remove /dev/sda1

mdadm --zero-superblock /dev/sda1

mdadm /dev/md2 --fail /dev/sda1

mdadm /dev/md2 --remove /dev/sda1

mdadm --zero-superblock /dev/sda1

badblocks -nvsf -c 98304 /dev/sda > /volume1/toto/sda.log 2>&1 &

 

Pour suivre l’évolution dans SSH, j’ai tapé cette commande.

 

tail -f /volume1/toto/sda.log

 

Ce test a pris environ 11 heures et 28 minutes. Il a pris environ 3% de CPU et environ 26% de RAM.

Quand ce test a été terminé, j’ai redémarré le NAS et je suis allé dans le gestionnaire de stockage \volumes \ réparer. Le système est revenu dans un mode normal.

Donc, pour faire un résumé, ces 3 tests ont été faits en moins de 2 jours.

Le premier test a été fait sur 2 disques neufs de 6 To. Cela a prit environ 10 heures (ce test c'est terminé en pleine nuit, donc je n’ai pas le temps exact). Le besoin de RAM a été fixe à 33%.

Par contre, la demande CPU oscillait entre 1 et 4 %, avec quelques pointes plus élevées occasionnellement.

Le deuxième test a été fait sur 1 disque de données de 6 To. Cela a pris environ 11 heures 13 minutes. Le besoin de RAM a été fixe à 26%.

La demande CPU oscillait entre 1 et 4 %, avec quelques pointes plus élevées occasionnellement.

Le troisième test a été fait sur 1 disque de données de 6 To. Cela a prit environ 11 heures 28 minutes. Le besoin de RAM a été fixe à 26%.

La demande CPU oscillait entre 1 et 4 %, avec quelques pointes plus élevées occasionnellement.

Encore merci à Firlin, ainsi que tous ceux qui ont contribué à améliorer ce tuto.

Norm

 

 

Voici les résultats.

Modifié le 1 mars 2019 par Norm
J'ai corrigé une erreur dans le texte

[firlin]

Merci @Norm  de ton retour.

c'est pas des disques de 6To au lieu de 6Go 😁

Modifié le 5 février 2019 par firlin

[Norm]

Désolé @firlin, tu as entièrement raison. Je vais corriger mon message.

Norm

[perduici]

Bonjour

Quelqu'un a des infos concernant le test des badblocks et les disques ssd?

L'utilité, la nécessité ou alors, on s'en tape complètement?

 

merci

Bob

[firlin]

@perduici

Pour moi cela n'a aucune utilité de faire un badblock sur des SSD, il y a pas de mécanique donc aucune raison que les SSD soit detruit pendant le transport contrairement à un disque dur.

[unPixel]

Je pencherai aussi comme firlin mais j'ajouterai qu'il faut quant même le tester avec par exemple un logiciel constructeur pour s'assurer qu'il est quand même sain avant de le mettre en production.

[Jojo (BE)]

de plus les SSD sont plus sensibles aux écriture multiples : exile, ne jamais faire de defragmentation Windows sur un disque SSD. Donc je ne le tenterais pas avec Badblocks