[TUTO] Préparation des disques avec Badblocks

[koblar]

Il y a 4 heures, firlin a dit :

Bonjour @koblar, 
Tu n'avais pas crée le dossier partager toto sur ton nas ? car c'est dans celui-ci qu'est stocker le resultat du test au fur et à mesure. 
 

Bonjour @firlin: J'avais crée le dossier "toto" en ligne de commande (mkdir -p /volume1/toto) mais je ne suis pas convaincu que ça ai fonctionné car je ne voyais pas le dossier sous DSM!? Pour la préparation du test du deuxième disque j'ai crée le dossier directement depuis DSM.

En ce qui concerne le suivi de l'avancement j'ai utilisé la commande: tail -f /volume1/toto/sdX.log qui affiche le pourcentage de progression dans la fenêtre Putty. Le résultat en lui même aurait dû être enregistré dans le fichier log mais malheureusement le test a été interrompu avant la fin (est-ce pour cela que le fichier n'a pas été crée correctement?)

 

[firlin]

Bonjour @koblar, 
cela explique ton souci le dossier Toto il faut le faire au moyen d'un dossier partager.
Ensuite la commande tail elle est coupé quand tu fermes la fenêtre terminal. Dans ce cas le fichier log n'est pas stocker d'après mes souvenirs 

[koblar]

Bonjour @firlin J'ai effectivement mal géré la création du dossier partagé. Toutefois, sans perte de connection mon test Badblocks serait allé au bout, je n'ai jamais fermé la fenêtre Putty 😪

Du coup pour le second disque, j'ai bien crée le dossier toto depuis DSM et je vais lancer les commandes suivantes:

Nohup badblocks -wvs -b 4096 -c 491520 /dev/sata3 > /volume1/toto/sata3.log 2>&1 &    

et pour le suivi de la progression:

ps aux | grep badblocks 

Tu as une remarque ou cela te semble correcte ?

Merci

[firlin]

Bonjour @koblar, 
Si tu suis le tutos en 1er page cela fonctionne très bien ( pour info j'ai refait un test sur un disque de 6to récemment).

Apres tu peux adapter pour suivant tes contraintes   

[koblar]

Bonjour,

 @firlin: Je viens d'avoir exactement le même problème que pour le premier disque: au bout de plus de 18h de test Putty plante (Fatal error). 😡 

Je pensais que c'était dû à une fermeture inopinée du terminal liée à une perte de connexion et j'avais donc bien utilisé la commande "nohup" mais même résultat. Bon, le seul côté positif c'est que jusque là pas d'erreur detéctée (0/0/0)

Malheureusement je n'ai pas pensé à faire une capture de la fenêtre d'erreur Putty

Une idée de ce qui a pu se passer ?

Modifié le 6 mars par koblar

[Vista1967]

Bonjour,

Aujourd'hui, j'ai reçu 2 disques Synology HAT3300-4T et je me demande s’il est nécessaire de faire une procédure pour le parking des têtes (tête de lecture/écriture).Comme nous l'avons fait précédemment pour les WD Red augmenté le délai de parking des têtes de 8 à 300 secondes plus test à l'aide de l'utilitaire WDIDLE3.

Ou peut-être tester avec badblocks je n’ai jamais fait ça mais si c’est nécessaire, je suivrai tutoriel du forum ?

Je ne suis pas certain d'avoir été suffisamment clair dans mes explications, c'est pourquoi j'ai joint une capture d'écran pour illustrer mon propos.

Merci d’avance !

[firlin]

Bonjour @Vista1967, 
La procédure avec WDIDLE3 ne fonctionnaient que pour les disques dur de marque WD. Elle n'est plus d'actualité car le souci a été resolu depuis le temps ( cela date des disques GREEN plus de 10 ans voir 15).

Ensuite a toi de voir si tu veux préparer les disques avant de les monter dans le nas.
Je n'ai jamais fait de test badblock sur des disques Synology ( en réalité c'est des Toshiba).

[Vista1967]

Parfait, cela signifie que ce n'est plus un problème. Je vérifierai si Toshiba propose des recommandations ou un outil de test avant utilisation.

Merci beaucoup !

[PiwiLAbruti]

Le firmware de ces disques est géré par Synology. Si tu as des doutes sur les valeurs S.M.A.R.T. des disques, contacte le support Synology depuis le Centre d'assistance inclus dans DSM.

S'il y a effectivement une anomalie, ce sera corrigé par une mise à jour automatique du firmware dont tout le monde pourra bénéficier.

[Vista1967]

Merci pour l'information !

Donc, le test avec badblocks n'est plus indispensable comme avant ?

C'est une circonstance atténuante positive, grâce aux nouvelles règles et restrictions de Synology pour les modèles DS à partir de la série 25 🙂

[Mic13710]

Il y a 3 heures, Vista1967 a dit :

Donc, le test avec badblocks n'est plus indispensable comme avant ?

Ca n'a pas de rapport. Le test badblocks permet de vérifier la surfacer du disque. Il est toujours préférable d'effectuer un test des disques, quelles que soient leurs marques, avant de les mettre en production.

[Vista1967]

C'est exactement ce que je pensais, mais peut-être que je n'ai pas bien formulé ma question 🙂

Je procéderai ainsi, c'est la solution la plus sûre pour mon prochain nouveau NAS.

Merci beaucoup pour vos conseils !

[Alm]

Hello @firlin,c'est encore moi et mes soucis de badblocks 🙈

J'ai reçu un quatrième IronWolf Pro de 16To et suis encore en train de galérer 😪. Pour rappel, mon historique avec les IronWolf Pro 16To :
- HDD N°1 (ST16000NE000, monté dans le DS415play, avec DSM6) vérifié avec succès via le terminal
- HDD N°2 (ST16000NE000, branché en USB sur le DS1819+, avec DSM6) vérifié avec succès via une tâche 🤩
- HDD N°3 (ST16000NT001, branché en USB sur le DS1819+, avec DSM7) échec et abandon... (puis mis en service)
Et aujourd'hui :
- HDD N°4 (ST16000NT001, branché en USB sur le DS1819+, avec DSM7)... nouvel échec (!).

Espérant reproduire le succès du HDD N°2, j'ai procédé ainsi :

1. Connexion du disque dur à tester via un boîtier USB3
2. Dans DSM > Panneau de configuration > Périphériques externes, formatage du disque dur en EXT4.
3. Activation de SSH & du compte admin
4. Ouverture du Terminal (Mac)
5. Commande pour se connecter : SSH admin@192.168.1.* puis saisie du MDP
6. Passage en mode admin avec commande : sudo -i puis saisie du MDP admin
7. Saisie de la commande suivante pour obtenir la liste des disques et volumes :
   fdisk -l | grep '/dev/[sh]d\|sata[[0-9]\|[a-z]]'
   Dans mon cas, ayant déjà une clé USB connectée (ayant la lettre u), le disque externe a la lettre v (avec une seule partition, sdv1).
8. Dans la mesure où le NAS a eu moins 8Go de RAM, j'ai opté pour la valeur -c 393216 (soit 4Go de RAM... le max je crois).
9. Création d'une tâche dans DSM avec l’utilisateur root.
10. Script de la tâche :
    badblocks -nvsf -c 393216 –b 4096 /dev/sdv1 > /volume1/logs/sdv1_20250723.log 2>&1 &
11. Exécution manuelle
12. Résultat : badblocks: invalid first block - /dev/sdv1

J'ai également testé tout cela sans formater le disque (à peine déballé), puis formaté en EXFAT, avec le même résultat... Je sèche un peu et ne comprends pas : quand j'avais procédé ainsi avec mon HDD N°2 (dans un boîtier externe et avec une tâche, via le DS1819+ et DSM6), ça avait fonctionné à merveille (et plutôt rapidement!). Les deux seules différences que je vois sont la version du disque (ST16000NT001 et non plus ST16000NE000) ainsi que le DSM (passé de DSM6 à DSM7). Autant dire que ça me dépasse (!).

Par ailleurs, je m'en sortais tant bien que mal avec les mes précédents IronWolf "pas Pro" (6 et 8To), via le DS415play et une commande dans le Terminal (Mac).

Bref, aurais-tu une idée de comment régler le problème, s'il-te-plaît? À défaut, je testerais ce nouveau HDD un temps avant de le mettre en service.

Modifié hier à 05:44 par Alm
Précisions et mise en forme.

[firlin]

Bonjour @Alm, 
Tu as essayer la commande suivante :  

Citation

badblocks -nvsf -c 393216 –b 4096 /dev/sdv > /volume1/logs/sdv.log 2>&1 &

Car si je me souviens bien pour les disques USB pas besoin de mettre l'argument après la lettre de celui-ci.
C'est noté comme ca dans le tutos page 1 

[Alm]

Merci @firlin pour ton aide 🙂

C'est effectivement la première chose que j'ai faite, avant de formater le disque, comme dans le tuto. 😕 (Avec le HDD N°2, ça avait fonctionné à merveille pourtant.) D'ailleurs, la commande "fdisk -l | grep '/dev/[sh]d\|sata[[0-9]\|[a-z]]'" me listait bien le disque sdv, sans partition sdv1. (Logique ^^)

Je viens de réessayer et j'obtiens le même résultat : badblocks: invalid first block - /dev/sdv

Bizarre... 😕

[firlin]

Bonjour @Alm, 
Désole je t'ai un peu oublié 
Sais tu me poster le retour de la commande suivant : fdisk -l | grep '/dev/[sh]d\|sata[[0-9]\|[a-z]]'
 

Il me faut voir comment j'ai fait ma tache la derniere fois avec un disque de 8to WD Elements 

 

[Alm]

Bonjour @firlin,

T'inquiète pas, y a vraiment rien qui presse et t'es déjà super sympa d'aider tout le monde. Merci encore! 🙂

Voilà ce que me retourne la commande (j'ai juste surligné chaque disque) :
----

Disk /dev/sda: 14.6 TiB, 16000900661248 bytes, 31251759104 sectors

/dev/sda1         2048     4982527     4980480  2.4G Linux RAID

/dev/sda2      4982528     9176831     4194304    2G Linux RAID

/dev/sda5      9453280 11720838239 11711384960  5.5T Linux RAID

/dev/sda6  11720854336 15627846239  3906991904  1.8T Linux RAID

/dev/sda7  15627862336 31251540671 15623678336  7.3T Linux RAID

Disk /dev/sdb: 14.6 TiB, 16000900661248 bytes, 31251759104 sectors

/dev/sdb1         2048     4982527     4980480  2.4G Linux RAID

/dev/sdb2      4982528     9176831     4194304    2G Linux RAID

/dev/sdb5      9453280 11720838239 11711384960  5.5T Linux RAID

/dev/sdb6  11720854336 15627846239  3906991904  1.8T Linux RAID

/dev/sdb7  15627862336 31251540671 15623678336  7.3T Linux RAID

Disk /dev/sde: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors

/dev/sde1         2048     4982527     4980480  2.4G Linux RAID

/dev/sde2      4982528     9176831     4194304    2G Linux RAID

/dev/sde5      9453280 11720838239 11711384960  5.5T Linux RAID

/dev/sde6  11720854336 15627846239  3906991904  1.8T Linux RAID

Disk /dev/sdd: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors

/dev/sdd1     2048     4982527     4980480  2.4G Linux RAID

/dev/sdd2  4982528     9176831     4194304    2G Linux RAID

/dev/sdd5  9453280 11720838239 11711384960  5.5T Linux RAID

Disk /dev/sdc : 14.6 TiB, 16000900661248 bytes, 31251759104 sectors

/dev/sdc1         2048     4982527     4980480  2.4G Linux RAID

/dev/sdc2      4982528     9176831     4194304    2G Linux RAID

/dev/sdc5      9453280 11720838239 11711384960  5.5T Linux RAID

/dev/sdc6  11720854336 15627846239  3906991904  1.8T Linux RAID

/dev/sdc7  15627862336 31251540671 15623678336  7.3T Linux RAID

Disk /dev/sdh: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors

/dev/sdh1         2048     4982527     4980480  2.4G Linux RAID

/dev/sdh2      4982528     9176831     4194304    2G Linux RAID

/dev/sdh5      9453280 11720838239 11711384960  5.5T Linux RAID

/dev/sdh6  11720854336 15627846239  3906991904  1.8T Linux RAID

Disk /dev/sdg: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors

/dev/sdg1         2048     4982527     4980480  2.4G Linux RAID

/dev/sdg2      4982528     9176831     4194304    2G Linux RAID

/dev/sdg5      9453280 11720838239 11711384960  5.5T Linux RAID

/dev/sdg6  11720854336 15627846239  3906991904  1.8T Linux RAID

Disk /dev/sdf: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors

GPT PMBR size mismatch (239649 != 245759) will be corrected by write.

/dev/sdf1         2048     4982527     4980480  2.4G Linux RAID

/dev/sdf2      4982528     9176831     4194304    2G Linux RAID

/dev/sdf5      9453280 11720838239 11711384960  5.5T Linux RAID

/dev/sdf6  11720854336 15627846239  3906991904  1.8T Linux RAID

The backup GPT table is not on the end of the device. This problem will be corrected by write.

GPT PMBR size mismatch (4294967294 != 5860533167) will be corrected by write.

Disk /dev/sdu: 28.7 GiB, 30752000000 bytes, 60062500 sectors

/dev/sdu1          32 60062499 60062468 28.7G  c W95 FAT32 (LBA)

Disk /dev/sdi: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors

/dev/sdi1      40     409639     409600  200M EFI System

/dev/sdi2  409640 5860270983 5859861344  2.7T Microsoft basic data

Disk /dev/sdv: 14.6 TiB, 16000900661248 bytes, 31251759104 sectors

/dev/sdv1    256 31251758579 31251758324 14.6T Linux filesystem

---

Les 11 premiers sont les HDD internes du serveur (3 * 16TB + 1 * 6TB + 4 * 8TB) et toutes ces partitions viennent du fait que je suis en SHR1 sur les 8 disques. Les trois derniers sont les externes :
- Disk /dev/sdu:  est une clé USB.
- Disk /dev/sdi:  est un disque branché en esata pour un backup (seul ajout depuis mon message précédent).
- Disk /dev/sdv:  est le fameux disque dur que j'aimerais tester et vérifier, histoire de remplacer le 6TB.

Ça t'aide à y voir plus clair?

---

NB : pour rappel, mon script est bien le suivant : 
badblocks -nvsf -c 393216 –b 4096 /dev/sdv > /volume1/logs/sdv.log 2>&1 &

Modifié il y a 1 heure par Alm