[TUTO] Préparation des disques avec Badblocks

[firlin]

@MilesTEG1

Avec l'argument -w tu écris sur tous les secteur du disque et il vérifie (donc cela revient a faire deux passe , alors qu'avec le -n je fais un test de lecture des secteurs (une passe).

Je le comprend comme ca .

Dans tous les cas pour ma part je teste les disques neuf avec le badblock donc si j'ai trop d'erreur je renvoie direct.

 

[babble]

Non, pas exactement.

-w écrit un motif par secteur sur la totalité du disque, puis relit chacun des secteurs pour savoir si le motif a bien été écrit. Le programme recommence avec 3 autres motifs différents, ce qui fait au total 4 passes d'écriture + 4 passes de lecture.

Moi non plus je ne vois pas trop l'intérêt de faire un test de lecture uniquement (argument -n), car ce qui est intéressant, c'est de savoir si le disque va supporter l'écriture fiable + la conservation de la donnée sur chacun des secteurs.

Il est bon pour la production si les erreurs renvoyées sont de 0/0/0.

Modifié le 18 août 2020 par babble

[MilesTEG1]

Oh ! babble 😄  Je suppose que tu es le même que le taulier du sujet Syno de HFR 😉

Sinon, j'ai pas donné ici le temps pour 8To de badblocks : 114h 40min

Je vais en avoir pour quasi la même durée pour la copie des données 😇

[babble]

En personne 😉

Concernant la durée de la copie des données, ça devrait être beaucoup plus rapide, car tu ne traiteras pas 32To comme pendant le test Badblocks.

Modifié le 18 août 2020 par babble

[MilesTEG1]

il y a 20 minutes, babble a dit :

En personne 😉

Concernant la durée de la copie des données, ça devrait être beaucoup plus rapide, car tu ne traiteras pas 32To comme pendant le test Badblocks.

Ha oui vu comme ça, 32To ! Purée 😆
Oui du coup ça devrait aller plus vite ^^

[firlin]

@babble , ta remarque sur l’argument -w à la place du -n m'a interpelé.

Et au départ je lançais le test avec l’argument -W, comme tu le dis aussi dans ton tutos ( merci de me cité au passage) .

D'après moi le passage de l'argument -w à -n viens de cette explications https://wiki.archlinux.org/index.php/badblocks

Suite a certaines discutions on a du me faire la remarque que le -n serais plus simple et rapide

on est d'accord que le 1er est plus stressant pour les disques et donc plus long ==> donc mieux

Citation

Read-write test (warning: destructive)

This test is primarily for testing new drives and is a read-write test. As the pattern is written to every accessible block, the device effectively gets wiped. The default is an extensive test with four passes using four different patterns: 0xaa (10101010), 0x55 (01010101), 0xff (11111111) and 0x00 (00000000). For some devices this will take a couple of days to complete.

# badblocks -wsv /dev/device

Checking for bad blocks in read-write mode
From block 0 to 488386583
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: 22.93% done, 4:09:55 elapsed. (0/0/0 errors)
[...]
Testing with pattern 0x00: done
Reading and comparing: done
Pass completed, 0 bad blocks found. (0/0/0 errors)

 

Citation

Read-write test (non-destructive)

This test is designed for devices with data already on them. A non-destructive read-write test makes a backup of the original content of a sector before testing with a single random pattern and then restoring the content from the backup. This is a single pass test and is useful as a general maintenance test.

# badblocks -nsv /dev/device

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: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

 

[babble]

Ah, c'est plus clair.

L'argument -n permet de sauvegarder la donnée de chaque secteur d'un disque déjà utilisé (ou non, d'ailleurs), d'y écrire un motif, de le relire pour voir s'il a bien été écrit, et de remettre en place la donnée qui s'y trouvait. Badblocks fait ce test pour chaque secteur, mais une seule fois, contrairement à -w qui le fait 4 fois (en détruisant les données).

Du coup, pour préparer un disque destiné à plusieurs années de service, de mon point de vue, il vaut mieux être sûr de sa fiabilité, car on a vu des disques neufs flancher à la deuxième ou troisième passe de BadBlocks, ce qui signifie que l'argument -n n'aurait pas permis de mettre en évidence sa défaillance imminente.

Je pense que ça devrait être précisé dans ton tuto en FP 😉

 

[.Shad.]

Bonjour,

Je vais bientôt tester 2 WD Blue de 4 To chacun qui vont entrer en service dans un peu plus d'un mois.
Pour mon NAS, j'avais réalisé le test badblocks en suivant les recommandations du tutoriel et les explications additionnelles du lien fourni à la fin : https://www.pantz.org/software/badblocks/badblocksusage.html

Notamment pour le calcul du paramètre -c (Nombre de blocs testés en même temps).
D'une durée de 136h initiale j'étais passé à une 30aine d'heures qui étaient là tout à fait envisageables.

Mais je me pose la question de la fiabilité du test si on augmente le nombre de blocs testés simultanément. Est-ce que cela a un impact ? je viens de lire les derniers échanges concernant l'argument -n et -w et du coup je me permets de citer @firlin et @babble s'ils peuvent m'éclairer.

[babble]

Selon http://marionpatrick.free.fr/man_html/html/badblocks_8.html, plus c est élevé, plus badblocks est rapide et efficace. Ne pas dépasser c=totalRAMinstalléex3/32 /nombre de disques à tester simultanément. C est un multiple de 64, 98304 pour 1 disque et 1Go de RAM par exemple.

-c nombre-de-blocs

est le nombre de blocs à tester en une fois (16 par défaut). Accroître ce nombre augmentera l'efficacité de badblocks mais également son utilisation mémoire. Les besoins en mémoire de badblocks sont proportionnels au nombre de blocs à tester simultanément en mode lecture-seule, à deux fois ce nombre en mode lecture-écriture, et à trois fois ce nombre en mode lecture-écriture non destructif. Si vous fixez le paramètre nombre-de-blocs à une trop grande valeur, badblocks se terminera presque immédiatement sur une erreur manque-de-mémoire « lors de l'allocation de tampons mémoire » ; si vous le fixez trop bas pour un test en mode-écriture-non-destructif, alors il est possible que des blocs douteux présents sur un disque dur non fiable soient masqués par les effets du tampon de pistes du disque dur.

[.Shad.]

Ok donc c'est tout à fait safe et recommandé, et avec 16 Go de mémoire je devrais pouvoir considérablement réduire la durée des tests.
Merci beaucoup !

[MilesTEG1]

il y a 3 minutes, .Shad. a dit :

Ok donc c'est tout à fait safe et recommandé, et avec 16 Go de mémoire je devrais pouvoir considérablement réduire la durée des tests.
Merci beaucoup !

Tu as bien tester ta ram quand tu as ajouté la barrette supplémentaire ?
Bon badblocks ^^

Cependant, n'espère pas gagner des dizaines d'heures 😉 

[.Shad.]

Ce ne sera pas sur mon NAS mais sur mon serveur Linux maison, je compte faire un test mémoire en amont avant de faire le test badblocks 😉 

[MilesTEG1]

il y a 1 minute, .Shad. a dit :

Ce ne sera pas sur mon NAS mais sur mon serveur Linux maison, je compte faire un test mémoire en amont avant de faire le test badblocks 😉 

Ha oui je crois que tu l'avais dit avant 😅 Et c'est écrit aussi dans ta signature 😁

 

[rrulioo]

Bonjour !

Je vois que le test des disques est toujours d'actualité..... Donc je vais m'y coller ! (j'ai reçu ce matin 2 WD RED Plus 12To)

Pour faire ce test badblocks, est-il possible de le brancher en SATA dans mon PC Windows, et de faire le test avec une VM linux sous VirtualBox (afin de pouvoir toujours utiliser mon PC Windows) ?
Cela me permettrai d'aller plus vite que via mon NAS, et de ne pas monopoliser mon NAS aussi.
Pour l'instant je fais le test étendu via Data LifeGuard Diagnostics de WD (il m'annonce 16h de travail).

(sachant que j'y connais pas grand-chose à Linux et que mon utilisation de NAS est pour du stockage de données perso et pas entreprise).

Merci 🙂

[babble]

Tu es limité par la vitesse des disques. Tu n'iras donc pas plus vite dans le PC que dans le NAS.

De mon point de vue, le NAS étant un équipement censé être UP h24, il vaut mieux tester les disques dedans, la tâche est transparente et occupe très peu de ressources processeur, et ça évite de laisser tourner un PC supplémentaire pendant des jours pour ça.

[firlin]

@rrulioo le plus simple c'est de faire le test avec le nas sachant que tu peux le lancer avec une tache sur celui-ci.

Pour info on peut le faire avec un CD de boot avec Badblock dessus ( par contre tu monopolises le PC pendant x heures ou jour et si tu le coupe tu recommences à zero. idm avec une VM).

@babble c'est pas le disque qui limite mais la quantité de RAM que tu attribues au test badblock.

 

[babble]

Il y a 20 heures, firlin a dit :

c'est pas le disque qui limite mais la quantité de RAM que tu attribues au test badblock.

 

Ce que tu dis n'est vrai que si tu affectes une quantité de RAM relativement faible.

 

A partir du moment où tu affectes suffisamment de RAM, la limitation provient des disques. Les RED que j'ai testé jusqu'ici sont à environ 150Mo/s. Tu n'iras pas plus vite même si tu y affectes 1To de RAM, puisque cette vitesse du disque est limitée par conception et dépend des modèles de disques durs.

Modifié le 24 septembre 2020 par babble

[rrulioo]

J'avais bien vu que la RAM comptait pour le temps d'exécution, même si je ne suis pas énormément pressé... Mais 512Mo de RAM sur mon DS215j, contre 8Go que je peux allouer à la VM sur mon PC, je pense voir la différence. Et mon PC est très souvent allumé vu que je bosse avec en ce moment, donc ça n'est pas un critère pour moi.

Comme je veux mettre mes nouveaux disques pour remplacer mes anciens en SHR (dans le même NAS donc), si je met 1 nouveau disque en remplacement d'1 ancien, il va aussitôt me reconstruire le RAID donc je vais perdre un temps fou avant de pouvoir faire mon test ? Et pareil lorsque je mettrai le 2ème disque ?

Ou si je mets directement mes 2 nouveaux disques dans mon NAS pour faire les tests, je n'aurai plus accès à mes données le temps du test vu que mes anciens disques seront démontés, c'est pourquoi je pensais faire le test à l'extérieur du NAS.

Mais pour passer par la VM il me reste à affecter directement mon disque physique... j'ai trouvé une manip, à voir si ça fonctionne bien.

[firlin]

Bonjour rrulioo,

Si tu veux pas te prendre trop la tête tu peux monter les disques dans le nas un fois que tu as passé le logiciel de WD.c'est pas un test hard dans les règles de l'art mais déjà tu sais si ton disque a des problème de base.

[rrulioo]

Je veux bien me prendre la tête maintenant pour être tranquille plus tard. Je ne suis pas pressé, j'ai le temps d'attendre 😉. Le 1er disque a passé avec succès le test WD, en 20h. Là j'ai lancé le 2ème.

Ensuite je regarderai si je parviens à monter le disque physique dans la VM Linux pour faire le badblocks. (en fait, je me dis juste qu'avec la VM si le test dure plusieurs jours (ce qui sera le cas) mon Windows voudra redémarrer tout seul pour installer ses MAJ, et ça me plantera le test...). Tandis que dans le NAS je n'aurai pas de problème de redémarrage non souhaité.

[babble]

Windows 10 permet de suspendre les mises à jour pendant 7 jours.

Ainsi, il ne devrait pas redémarrer.

Modifié le 24 septembre 2020 par babble

[rrulioo]

Bien vu, c'est même jusqu'à 35 jours en allant dans les options avancées, merci 🙂 !

[rrulioo]

Ce matin j'ai créé ma VM Virtualbox (Ubuntu, 10Go RAM), créé un fichier disque qui correspond à mon DD physique, ajouté à ma VM, et démarré ma VM.

VBoxManage internalcommands createrawvmdk -filename D:\OrdinateursVirtuelsVirtualBox\testVM\RAW2.vmdk -rawdisk \\.\PhysicalDrive2

Dans Ubuntu, je vois bien un disque de 12To "sdb", sans partition.

J'ai créé une partition Ext4 (j'avais vu qu'il en fallait une), et lancé badblocks. J'ai essayé avec "-c 786432" (correspond à 8Go que je souhaite allouer) et avec "-c 98304" (le tuto original)

badblocks -nvs -c 786432 /dev/sdb > /home/ju/sdb1_5PGMZLZE.log 2>&1 &

La commande se termine instantanément, et le fichier log créé indique "badblocks: Valeur trop grande pour le type défini de données bloc de départ invalide (11718884376) : doit être une valeur sur 32 bit".

Vous avez une idée de mon erreur ?

[firlin]

Bonjour rrulioo,

Pas besoin de crée une partition ext4 sur ton disque de test.

Ensuite tu as alloué combien de RAM à ta VM ?

Ensuite il n'y a pas d'espace entre le sdb et >

Citation

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

 

[rrulioo]

J'ai alloué 10Go de RAM à ma VM

J'ai essayé sans l'espace, mais ça ne change rien.

(J'ai oublié de préciser, je me suis loggué en root (sudo -i), car avec mon compte le log disait "permission non accordée pour la détermination de la taille du périphérique")

Est-ce que le disque (12To) est trop gros et comporterait trop de blocs ?

Modifié le 25 septembre 2020 par rrulioo