[TUTO] Préparation des disques avec Badblocks

[bruno78]

Bonjour et bon dimanche,

comme je suis un peu têtu, j'ai continué avec mes tests "badblocks". Je voudrais essayer de comprendre. D'autant que le sujet "préparation des disques" en général est important compte tenu de l'usage d'un NAS, et de la confiance que l'on doit pouvoir avoir si on tient à ses données (ce qui ne dispense pas bien sûr d'organiser les sauvegardes externes).

J'ai refais le test avec un disque qui me sert de validation et pour des tests justement, donc non représentatif de ce que l'on mettrait a priori en production, et disque qui ne sert pas pour des données prod.

Résultats :

• sans "-c" (par defaut, 16 blocks) : 40 heures 53 minutes, 0/0/0 errors
• avec "-c 98304" : 7 heures 30 minutes , 0/0/4 errors

D'où les interrogations :

• quelle est la méthode la plus pertinente ? 
• pourquoi cette différence ?
• quelle pourrait être l’influence de la taille du cache disque sur la valeur du "-c" à adopter ?

Résultats bruts :

Disque en test : Hitachi Disque Dur 500Go SATA 2.5" Travelstar 7K500 HTS725050A9A364 Pc Portable 16Mo

• Test sans le paramètre "-c" :

badblocks -nvsf /dev/sda > /volume1/tmp/sda-20191026.log 2>&1 &

/dev/sda is apparently in use by the system; badblocks forced anyway.
Checking for bad blocks in non-destructive read-write mode
From block 0 to 488386583
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern:   
0.00% done, 0:00 elapsed. (0/0/0 errors)  
0.00% done, 0:01 elapsed. (0/0/0 errors)
<...>
<...>
100.00% done, 40:53:49 elapsed. (0/0/0 errors)
100.00% done, 40:53:50 elapsed. (0/0/0 errors)
100.00% done, 40:53:51 elapsed. (0/0/0 errors)done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

 

• Test avec le paramètre "-c" :

 

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

/dev/sda is apparently in use by the system; badblocks forced anyway.
Checking for bad blocks in non-destructive read-write mode
From block 0 to 488386583
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern:   
0.00% done, 0:01 elapsed. (0/0/0 errors)  
0.00% done, 0:03 elapsed. (0/0/0 errors)
<...>
0.50% done, 1:54 elapsed. (0/0/0 errors)
2491200
2491201
2491202
2491203
0.50% done, 1:56 elapsed. (0/0/4 errors)
0.52% done, 1:58 elapsed. (0/0/4 errors)
<....>
99.98% done, 7:30:06 elapsed. (0/0/4 errors)
99.98% done, 7:30:08 elapsed. (0/0/4 errors)
100.00% done, 7:30:09 elapsed. (0/0/4 errors)done                                                 
Pass completed, 4 bad blocks found. (0/0/4 errors)

Et pendant ce temps là, mon "badblocks" sans le paramètre "-c" sur mon disque WD 6To continue son petit bonhomme de chemin : on est parti pour 6 à 8 jours .... . Je le laisse tourner tranquillement. 0/0/0 errors pour le moment à 25% done.

[Lud]

Hello,

Désolé si ça a déjà été dit, je n'ai pas lu tout le fil.

Concernant l'utilisation d'un fichier de logs, je déconseille d'utiliser l'argument "-s". Ça précise la progression de la tâche, ce qui est bien pratique en ligne de commande, mais ça gonfle aussi le fichier de logs qui va rapidement atteindre plusieurs Go, carrément moins exploitable.
Pour moi, c'est soit l'un, soit l'autre, mais pas l'argument "-s" et le fichier de logs en même temps.

Deuxième point, autant l'argument "-c" est controversé :
https://unix.stackexchange.com/a/202579
https://askubuntu.com/questions/59425/how-do-i-choose-the-right-parameters-when-using-badblocks/400685#400685
Il peut être intéressant d'utiliser le script en lien pour faire des tests.

Ce site un peu ancien peut aussi donner un ordre d'idée des valeurs à essayer :

https://www.pantz.org/software/badblocks/badblocksusage.html
-> Total_RAM_en_Ko * 3 / 32 = valeur maximale de "-c". A répartir si plusieurs badblocks lancés en même temps.

Autant je pense que l'argument "-b" est important à correctement préciser.
Repérer votre disque :
fdisk -l | grep "/dev/[sh]d[a-z]"
Déterminer la taille de chaque secteur physique :
hdparm -I /dev/sdX | grep -i physical
Utiliser cette valeur après "-b".

Exemples :
Non destructif (Attention ! Pas sans danger pour les données !) :
badblocks -nv -b 512 /dev/sdX > /volume1/toto/badblocks_sdX.log 2>&1 &
badblocks -nv -b 512 -c 98304 /dev/sdX > /volume1/toto/badblocks_sdX.log 2>&1 &

Destructif (plus long et "use" plus le disque) :
badblocks -wv -b 512 /dev/sdX > /volume1/toto/badblocks_sdX.log 2>&1 &
badblocks -wv -b 512 -c 98304 /dev/sdX > /volume1/toto/badblocks_sdX.log 2>&1 &

[.Shad.]

Bonjour,

Je suis en train d'ajouter 2 disques WD Red de 3 To à mon DS918+ actuellement en SHR avec protection de données sur deux disques.
J'ai suivi la première méthode, via le planificateur, et j'ai laissé la taille de bloc par défaut (méthode lente). Pour l'instant seul un test a été lancé sur le disque 3 (sdc).
Des autres posts que j'ai vus, on doit compter environ une quarantaine d'heure pour le test d'un disque.
Là je suis l'avancement du test, je suis à 0.09% pour 16 minutes écoulées.

Je suis parti du principe que la vitesse d'analyse était linéaire, donc un rapide calcul : 100 / 0.09 = 1111 donc 1111 * 16 min ~ 17777 min => 17777 / 60 ~ 300 heures ??!
Je ne peux pas évidemment patienter tout ce temps, il y a visiblement quelque chose qui cloche, ou alors le postulat de linéarité de départ est faux.

Est-ce que quelqu'un a un avis sur la question ? Est-ce que je peux dans le pire des cas arrêter le test et augmenter la taille des blocs ? @firlin

Merci de vos retours !

Modifié le 10 janvier 2020 par .Shad.

[.Shad.]

 Visiblement je ne suis pas le seul avec ce problème, je ne sais pas comment j'ai fait ma première recherche pour ne rien trouver.
Je vais tuer le processus et augmenter le nombre de blocs, car 13 jours pour un test. 😄 😄 😄

22h par disque c'est déjà autrement plus acceptable. 🙂
Par contre j'ai lu que ce problème est surtout constaté sur les Seagate, dans mon cas ce sont des WD...
Curieux quand même.

Modifié le 10 janvier 2020 par .Shad.

[firlin]

Bonjour .Shad.,

tu as tappé quelle comande ?

Pour tuer le processus il faut passer en ligne de commande ( SSH + mode Admin).

[.Shad.]

Oui j'ai fait kill -9 pid_du_processus

La bonne nouvelle, j'ai pu recommencer et ça va prendre le temps normal.
La mauvaise nouvelle c'est qu'un des disques a déjà près de 2000 secteurs défectueux à... 20% de l'analyse ? Je vais laisser l'analyse se finir et renvoyer tout ça fissa avec le rapport badblocks 😛

[maxou56]

Bonsoir, @.Shad.

Pour info avec un DS918+ et un disque WD Red 4To "100.00% done, 33:30:17 elapsed. (0/0/0 errors)done"

avec la commande "badblocks -nvs -c 98304"

[mans25]

Bonjour à tous

Je suis sur le point d'ajouter un nouveau DD WD RED 4To dans mon NAS pour remplacer un DD crashé. Sur les conseils avisés de firlin, je vais lancer badblocks pour le tester.

Mais problème: je suis sous mac et les 2 logiciels proposés pour la procédure (wincp et putty) sont pour windows...

Comment faire dans un environnement mac SVP ?? Il y a un logiciel équivalent ?

(et d'ailleurs ce qui m'étonne, c'est que rien de ressort quand je fais une recherche "badblocks mac" sur ke forume....) Je ne dois quand même pas être seul sous mac à utiliser un mac !!

Merci bien de vos retours !

[.Shad.]

Je ne connais pas les Mac mais je crois que vous avez un terminal, Homebrew, non ?

[mans25]

Oui, il y a bien un terminal sur Mac, mais selon le tuto de firlin il faut utiliser wincp ou putty de toute façon, selon les 2 options...

Donc si qqun a une alternative (et l'explication qui va avec !) ce serait génial.

Merci bien

[firlin]

Bonjour @mans25

Avec un mac c'est encore plus simple pour ce connecter en SSH au nas.

regarde ça  https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_login_to_DSM_with_root_permission_via_SSH_Telnet

il y a Cyberduck pour mac qui est équivalemment de wincp

Si tu n'y arrives pas dit le moi.

Me faudrait améliore le tutos aussi

[mans25]

Merci firlin

En fait, j'ai récupéré un ordi portable sous windows et installé winscp dessus.

Par contre, j'ai abandonné la procédure badblocks car impossible de faire ce que tu expliques dans le tuto.😢 A l'étape où je lance winscp, je ne vois pas volume1 dans la liste des dossiers de la fenêtre de droite de winscp (en fait pour moi ça devrait être "volume2" car je n'ai plus qu'un seul volume nommé volume2 sur mon seul GdS2 après avoir enlevé mon DD1 crashé qui était le GdS1 contenant le volume1). Mais je ne sais pas si j'ai mal effectué les étapes précédentes avec le script dans DSM ou si c'est un problème avec winscp.

Donc je suis passé directement à l'ajout d'un nouveau DD au groupe de stockage en espérant bien fort que mon nouveau DD n'a pas de problème ! Et je me dis que je referai un test badblocks une fois le disque configuré, j'ai lu que ca pouvait se faire après....

Pour l'instant j'en suis à la synchronisation des 2 DD qui prends des plombes et des plombes !

 

[maxou56]

Bonjour, @mans25

Tu parles de script et de winscp (terminal sur mac est plus simple).

Mais en faite il faut soit créer une tache dans DSM, avec par ex la commande "badblocks -nvs -c 98304 /dev/sda > /volume2/Test/DD01.log 2>&1 &" et l'utilisateur "root" (exécuter manuellement, pas de programmation)("sda" pour le disque1, b=2, c=3....)

 

Ou via le terminal sur mac:

Pour ce connecter au NAS il faut taper: "ssh utilistateuradmin@ipdunas -p22"  

Puis taper "sudo -i" (le mot de passe est celui de admin) pour passer en root.

Une fois en root, taper par ex la commande "badblocks -nvs -c 98304 /dev/sda > /volume2/Test/DD01.log 2>&1 &" 

 

La commande est à modifie (c'est un exemple), avec le bon disque et bon volume et le bon dossier partagé.

Modifié le 11 janvier 2020 par maxou56

[mans25]

Merci de ton retour maxou56.

Je parlais du script qui apparait dans le gestionnaire de tache de DSM. Rien ne s'est passé quand je l'ai exécuté, en tout cas rien de visible, c'est pour ça que je disais que j'avais peut-être mal exécuté cette étape.

Ou alors le "bug" a été dans winscp. Mais vu mon niveau je n'arrive pas à savoir ! Pourtant, j'ai bien suivi à la lettre, mais bon il suffit d'un espace mal mis peut-être (j'ai bien fait attention mais bon...).

 

Tu confirmes que badblocks peut se faire une fois le disque installé en RAID, même s'il a des données dessus (j'avais lu ça dans un fil) ou ce sera trop tard ?

SI tu me dis que c'est bon, j'essaierai tes lignes de commandes dans le terminal mac (mais pas avant 4-5 jours vu la vitesse à laquelle se synchronise mon nouveau DD : pour l'instant 4% en 5h donc j'y serai encore en fin de semaine prochaine !!!). 

Quand tu mets "ssh utilistateuradmin@ipdunas -p22", c'est vraiment "@ipdunas" qu'il faut écrire ou c'est un exemple à remplacer par l'ip qui apparait dans la barre d'adresse internet de DSM ? (désolé pour ces questions tui doivent être basiques mais je me forme tout doucement sur le tas en lisant ce forum - merci à vous tous en passant pour votre aide !)

Merci

[maxou56]

il y a 29 minutes, mans25 a dit :

Je parlais du script qui apparait dans le gestionnaire de tache de DSM. Rien ne s'est passé quand je l'ai exécuté, en tout cas rien de visible, c'est pour ça que je disais que j'avais peut-être mal exécuté cette étape.

Il n'y a rien de visible quand tu exécute la commande, juste l'a création d'un fichier .log à l'endroit ou tu l'as décidé.

il y a 29 minutes, mans25 a dit :

Ou alors le "bug" a été dans winscp. Mais vu mon niveau je n'arrive pas à savoir ! Pourtant, j'ai bien suivi à la lettre, mais bon il suffit d'un espace mal mis peut-être (j'ai bien fait attention mais bon...).

Aucun intérêt pour toi d'utiliser winscp.  Sur mac tu vas dans ton le Finder, puis sur le NAS, tu choisi le fichier .log et il va souvrir (avec un app système "console").

il y a 29 minutes, mans25 a dit :

Tu confirmes que badblocks peut se faire une fois le disque installé en RAID, même s'il a des données dessus (j'avais lu ça dans un fil)

Non. (Enfin c'est possible, mais il faut éjecter le Disque de la Raid, il faudra alors la réparer après. Si SHR, Raid1, Raid5 pas de perte de données)

 

il y a 29 minutes, mans25 a dit :

Quand tu mets "ssh utilistateuradmin@ipdunas -p22", c'est vraiment "@ipdunas" qu'il faut écrire ou c'est un exemple à remplacer par l'ip qui apparait dans la barre d'adresse internet de DSM ?

Oui via l'ip local du NAS.

Pour ce connecter en ssh à son NAS via le terminal de macOS, il faut que le service ssh soit activé sur le NAS.

Puis dans terminal taper "ssh utilistateuradmin@192.168.0.1" (si tu as modifier dans le NAS le port pour SSH par 9999), alors "ssh utilistateuradmin@192.168.0.1 -p9999"

 

 

 

 

 

Bonjour, @.Shad.

Sur mac il y a le terminal. (bash par défaut, mais zsh possible depuis catalina)

Pour gérer plusieurs connections ssh, il y a une app pas mal "Core Shell" sur le Mac App Store

Pour Homebrew c'est un gestionnaire de paquet comme app-get...

Modifié le 11 janvier 2020 par maxou56

[.Shad.]

Ah ok merci, j'ai jamais eu un Mac entre les mains 😛

[mans25]

Merci maxou56.

Donc pour moi c'est rapé alors le processus badblocks.... Maintenant que j'ai lancé la synchronisation, je ne vais pas rééjecter le disque et tout recommencé.

Je vais simplement prier fort pour que le disque soit en bon état !

Merci encore

[_DR64_]

J'ai un petit doute, je viens de m'acheter un DS918+, j'en profite pour faire un badblock sur 3 disques de 8TO.
J'ai lancé mes 3 taches en simultanée depuis environ 45 minutes. (DSM est sur un disque à part) 
ça m'affiche actuellement ça :

Checking for bad blocks in non-destructive read-write mode
From block 0 to 3519059287
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern:   0.00% done, 0:00 elapsed. (0/0/0 errors)

Normal que tout est à 0 au bout de 45 minutes ? ça avance progressivement ou on ne voit seulement le résultat qu'à la fin du badblock ?

Merci d'avance pour votre retour !

PS : CPU à 6% et RAM à 5%

Modifié le 24 janvier 2020 par Sweet64

[firlin]

Bonjour Sweet64,
 

il y a une heure, Sweet64 a dit :

Checking for bad blocks in non-destructive read-write mode
From block 0 to 3519059287
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern:   0.00% done, 0:00 elapsed. (0/0/0 errors)

tu es aller lire les info dans le fichier log ? ou directement dans l'interface ?

Normalement le fichier log se remplie au fur et à mesure.

 

[_DR64_]

C'est bon en fait @firlin, j'avais pas vu que je pouvais descendre 😂#GrosBoulet (même pas 1% en 3heures ça promet.... )

C'est normal ?

Modifié le 24 janvier 2020 par Sweet64

[firlin]

J'aurais tendance a dire oui, tu as tapé quelle ligne de commande simple ou speed ? 

[_DR64_]

Simple... Je pense que je vais annuler et faire en speed car c'est vraiment trop long ! lol

Je dirai même plus, je viens d'annuler et de relancer sur 2 disques avec :
badblocks -nvs -c 98304 /dev/sdx > /volume1/toto/sdx.log 2>&1 &

[cdarsac]

Bonjour,

Je suis en train d'utiliser la procédure pour tester un disque dur.

Cela semble bien fonctionner, mais la progression de la tache s'affiche en dynamique dans ma fenêtre "putty" plutôt que dans le fichier de log "/volume2/toto/sdea.log" qui reste vide.

 

Fenêtre "putty" de lancement:

root@NAS-DS918:/dev# badblocks -nvsf -c 98304 /dev/sdea > /volume2/toto/sdea.log &
[1] 22592
root@NAS-DS918:/dev# /dev/sdea is apparently in use by the system; badblocks forced anyway.
Checking for bad blocks in non-destructive read-write mode
From block 0 to 3907018583
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern:   0.23% done, 4:49 elapsed. (0/0/0 errors)
root@NAS-DS918:/dev#   0.29% done, 6:06 elapsed. (0/0/0 errors)

 

Fichier de log:

root@NAS-DS918:/volume2/toto# ls -la
total 0
drwxrwxrwx  1 root root 28 Feb 22 06:16 .
drwxr-xr-x  1 root root 28 Feb 22 05:15 ..
drwxrwxrwx+ 1 root root  8 Feb 22 05:16 @eaDir
-rwxrwxrwx  1 root root  0 Feb 22 06:14 sdea.log
root@NAS-DS918:/volume2/toto# cat sdea.log
root@NAS-DS918:/volume2/toto#

 

Qu'en pensez-vous ?      🙂

[pluton212+]

Salut,

je pense que si le log reste vide c'est qu'il n' a pas de "badblocks".

Modifié le 22 février 2020 par pluton212+

[cdarsac]

il y a une heure, pluton212+ a dit :

Salut,

je pense que si le log reste vide c'est qu'il n' a pas de "badblocks".

Ce peut-être une bonne raison en effet, ou pas !         😉

Modifié le 22 février 2020 par cdarsac