firlin Posté(e) le 25 septembre 2020 Auteur Posté(e) le 25 septembre 2020 il y a 4 minutes, rrulioo a dit : Est-ce que le disque (12To) est trop gros et comporterait trop de blocs ? Je pense pas car j'ai fait un test avec un disque de 10to dans un boitier USB, brancher au nas. Qaund tu tapes cette commande tu as quoi en retour ? Citation fdisk –l 0 Citer
rrulioo Posté(e) le 25 septembre 2020 Posté(e) le 25 septembre 2020 (modifié) Je ne peux pas faire de copier-coller, j'espère recopier sans erreurs 😄 Disque /dev/sdb : 10,94 TiB, 12000138625024 octets, 23437770752 secteurs Disk model: VBOX HARDDISK Unités : secteur de 1 x 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Modifié le 25 septembre 2020 par rrulioo 0 Citer
babble Posté(e) le 25 septembre 2020 Posté(e) le 25 septembre 2020 (modifié) Je suis surpris de voir que la taille des blocks physiques est en 512 et pas 4096... Il me semble que depuis 2011 tous les disques ont des tailles de blocks 4K https://en.wikipedia.org/wiki/Disk_sector Rajoute l'argument -b 4096 pour voir ce que ça donne, et -c 98304. Si ça marche, tu peux tenter d'augmenter -c Modifié le 25 septembre 2020 par babble 0 Citer
rrulioo Posté(e) le 25 septembre 2020 Posté(e) le 25 septembre 2020 (modifié) Peut-être que le "512" vient du fait que mon disque est monté dans la VM ? Bien vu, ça fonctionne avec "-b 4096 -c 98304"... J'ai tenté le -c 294912 (équivaut à 3Go de RAM selon le calcul) et ça fonctionne (en consommant réellement 3,5Go de RAM, vérifié avec top), mais -c 393216 (4Go de RAM) ça ne fonctionne plus. Bizarre car il me semblait que certains avaient pu allouer 8Go de RAM, mais c'est pas grave, je lance avec ça (au bout de 0,05% j'ai 0 erreurs 😅). Merci pour votre aide ! Modifié le 25 septembre 2020 par rrulioo 0 Citer
babble Posté(e) le 25 septembre 2020 Posté(e) le 25 septembre 2020 @firlin : Tu pourrais mettre à jour ton tuto STP ? Pour préciser l'argument -b 4096 ainsi que dire que -c 98304 correspond au test d'1 disque sur un système disposant d'1Go de RAM. 0 Citer
apossium Posté(e) le 1 octobre 2020 Posté(e) le 1 octobre 2020 Le 19/08/2020 à 10:13, babble a dit : 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. @babble: la raison du choix de l'argument -n vient de cet échange : Personne n'ayant rectifié, contredis ces informations … je les considère comme valable. Au début, j'utilisais l'argument -w. Seulement les vérifications sont très longues et quand on vend une grappe de 3, voire 5 x disques de 4, 8, voire 12 To … le client n'attendra pas plusieurs jours voire 1 mois pour recevoir son NAS … surtout quand c'est pour remplacer un NAS / un disque en prod … C'est compliqué de vérifier des disques à l'avance également, pusique ca immobilise les disques et que les tarifs bougent pas mal … par exemple avec 4 x 12 To, ca commence à douiller … peu de société peuvent se permettre ca … faut avoir du volume que je n'ai pas … --- De fait, j'utilise l'argument -n avec les réglages adaptés pour la RAM. Sur tous les disques vérifiés (une bonne 50 aine), - une bonne 10aine HS (à cause de transport je pense > emballage nok), donc détecté … - aucun early failure (0-6 mois) (objet du badblocks à mes yeux), - deux disques morts avant la fin de garantie, entre 1 et 2 an d'usage … et bien évidemment c'étaient des WD purple … (je n'en utilise plus aucun depuis). --- Une autre piste … Depuis, je compte regarder les résultats avec badblocks en USB, puisque cela permet d'arrêter les tâches et/ou les disques de manière différenciée (qd plusieurs disques en mm tps) … Quand les disques sont sur le bus SATA, on doit attendre la fin des tests de tous les disques (hotplug non possible selon pc utilisé) … et parfois certains essais bloquent la machine (un disque peut faire planter la machine si il est défectueux) … ce qui peut être assez problématique quand tu vérifies 4 x 12 To en meme temps et que tu dois tout recommencer … grrrrr 0 Citer
rrulioo Posté(e) le 6 octobre 2020 Posté(e) le 6 octobre 2020 Ca y est, les tests de mes 2 disques se sont bien terminés : 85 heures chacun, et 0 erreurs 🙂 Merci pour votre aide ! 0 Citer
babble Posté(e) le 6 octobre 2020 Posté(e) le 6 octobre 2020 Il y a 13 heures, rrulioo a dit : Ca y est, les tests de mes 2 disques se sont bien terminés : 85 heures chacun, et 0 erreurs 🙂 Merci pour votre aide ! 85 heures pour 12To avec l'argument -w ou -n ? Parce que ça ferait moins de 7 heures par To, ce qui est presque 3 fois moins que d'habitude... 0 Citer
MilesTEG1 Posté(e) le 7 octobre 2020 Posté(e) le 7 octobre 2020 Il y a 6 heures, babble a dit : 85 heures pour 12To avec l'argument -w ou -n ? Parce que ça ferait moins de 7 heures par To, ce qui est presque 3 fois moins que d'habitude... Hello @babble 👋 Je pense que c'est l'argument -n qu'il a utilisé vu que ce topic prône davantage son usage plutôt que le -w... 0 Citer
babble Posté(e) le 7 octobre 2020 Posté(e) le 7 octobre 2020 Effectivement, vu dans son message du 25 septembre. 0 Citer
rrulioo Posté(e) le 7 octobre 2020 Posté(e) le 7 octobre 2020 Je confirme, j'ai utilisé le "-n" comme indiqué ici badblocks -nvs -b 4096 -c 294912 /dev/sdb > /home/xxx/xxx.log 2>&1 & Cela aurait été mieux, ou indispensable de faire avec le "-w" ? Je n'ai pas encore mis rapatrié mes données sur mes nouveaux disques, il n'est donc pas encore trop tard pour que je fasse ce test... 0 Citer
babble Posté(e) le 7 octobre 2020 Posté(e) le 7 octobre 2020 (modifié) Je pense que le premier post devrait être un peu remanié pour apporter des précisions entre -n et -w, ainsi que les autres précisions que j'ai demandé à firlin le 25 septembre. De mon point de vue, tu aurais dû faire le test avec -w, mais le fait de l'avoir fait en -n assure déjà une certaine préparation. Je ne le referais pas. Par contre, dans ce cas, je ferai la préparation complète par DSM à l'initialisation (que je ne fais pas en sortant d'un badblocks -w ) Modifié le 8 octobre 2020 par babble 1 Citer
rrulioo Posté(e) le 8 octobre 2020 Posté(e) le 8 octobre 2020 (modifié) J'ai fait la préparation complète par DSM à l'installation, mais en allant dans le gestionnaire de disques j'ai vu qu'il faisait une "vérification de la cohérence" (ou quelque-chose de similaire, je ne me souviens plus). Cela correspond bien à un test des disques ? J'ai plus eu l'impression qu'il s'agissait d'une comparaison entre les 2 disques (j'ai créé un volume SHR), même s'il n'y avait encore aucune donnée. Cette vérification a pris environ 13h pour les 2 disques. EDIT : voici le texte affiché par le Syno : "Une vérification de cohérence de la parité est actuellement exécutée sur et peut affecter la performance globale du système" Et le résultat : "Consistency check of storage pool 1 on xxx has ended. No abnormality has been found." Modifié le 8 octobre 2020 par rrulioo 0 Citer
babble Posté(e) le 8 octobre 2020 Posté(e) le 8 octobre 2020 (modifié) Oui, il a fait la vérification du disque dont je parlais plus haut. Cette "cohérence" est vérifiée même avec un seul disque dans le NAS, aucune histoire de volume SHR en miroir là-dedans. De mon point de vue, le NAS est bon pour le service. Modifié le 8 octobre 2020 par babble 0 Citer
rrulioo Posté(e) le 8 octobre 2020 Posté(e) le 8 octobre 2020 OK merci pour ton retour ! C'est parti pour le transfert 😄 0 Citer
babble Posté(e) le 8 octobre 2020 Posté(e) le 8 octobre 2020 N'oublie pas les sauvegardes pour autant 😉 0 Citer
maxou56 Posté(e) le 26 octobre 2020 Posté(e) le 26 octobre 2020 (modifié) Le 17/09/2017 à 12:36, firlin a dit : Dans le NAS les disques sont nomme comme suivant sd + une lettre de l’alphabet : Disque 1 : sda Disque 2 : sdb Disque 3 : sdc Disque 4 : sdd Bonsoir, Sur les nouveaux NAS (DS220+, DS420+, DS720+, DS920+, DS1520+, DS1621+) Les disques sont nommés différemment. Disque 1 : sata1 Disque 2 : sata2 Disque 3 : sata3 Disque 4 : sata4 .... Merci @MilesTEG1 pour l’info 👍 Modifié le 27 octobre 2020 par maxou56 1 Citer
firlin Posté(e) le 27 octobre 2020 Auteur Posté(e) le 27 octobre 2020 Merci [mention]maxou56 [/mention] pour l’info je vais rajouter l’info dans le tutosEnvoyé de mon iPhone en utilisant Tapatalk 0 Citer
MilesTEG1 Posté(e) le 27 octobre 2020 Posté(e) le 27 octobre 2020 Il y a 7 heures, maxou56 a dit : Bonsoir, Sur les nouveaux NAS (DS220+, DS420+, DS720+, DS920+, DS1520+, DS1621+) Les disques sont nommés différemment. Disque 1 : sata1 Disque 2 : sata2 Disque 3 : sata3 Disque 4 : sata4😇 .... Je pensais avoir donné l'info ici aussi 😅 Je n'ai du le faire que HFR 😇 Du coup, je reposte ici deux commandes qui permettent de liste les disques présents en tenant compte de la nouvelle nomenclature : fdisk -l | grep '/dev/[sh]d\|sata[[0-9]\|[a-z]]' ls /dev/ | grep '/dev/[sh]d\|sata[[0-9]\|[a-z]]' Ha bah en fait si 😛 je l'avais dit ici : (je me disais bien que je l'avais fait 😁) 1 Citer
totoleouf Posté(e) le 26 novembre 2020 Posté(e) le 26 novembre 2020 salut à tous, j'ai suivi le tuto pour préparer un HDD de 10to. il est branché en Usb3: j'ai lancé la commande suivant : badblocks -nvs -c 393216 –b 4096 /dev/sdq > /volume3/docker/sdq.log 2>&1 & mais quand je veux suivre l'évolution avec la commande: tail -f /volume3/docker/sdq.log j'obtiens cela : badblocks: invalid first block - /dev/sdq ou est mon erreur? merci, 0 Citer
firlin Posté(e) le 26 novembre 2020 Auteur Posté(e) le 26 novembre 2020 Bonjour totoleoufTu es sur que ton disque monter dans un boîtier usb est bien nommé sdq ??Comme tu l’a spécifié dans ta commande ?Envoyé de mon iPhone en utilisant Tapatalk 0 Citer
totoleouf Posté(e) le 26 novembre 2020 Posté(e) le 26 novembre 2020 (modifié) il y a 8 minutes, firlin a dit : Bonjour totoleouf Tu es sur que ton disque monter dans un boîtier usb est bien nommé sdq ?? Comme tu l’a spécifié dans ta commande ? Envoyé de mon iPhone en utilisant Tapatalk oui oui il est dans son boitier usb au fesse du syno et oui j'ai vérifié avec la commande (fdisk -l) Disk /dev/sdq: 9.1 TiB, 10000797794304 bytes, 19532808192 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Modifié le 26 novembre 2020 par totoleouf 0 Citer
firlin Posté(e) le 26 novembre 2020 Auteur Posté(e) le 26 novembre 2020 Le volume 3 est un volume sur ton nas ?Le dossier docker est un dossier que tu as créé ou bien c’est celui que créer le nas quand on installe le paquet docker?( dans le cas du dernier point je suis pas sûr que l’on puisse écrire dedans comme ça )As tu essayer de crée un autre dossier partager et de faire avec celui-ci ?Envoyé de mon iPhone en utilisant Tapatalk 0 Citer
totoleouf Posté(e) le 26 novembre 2020 Posté(e) le 26 novembre 2020 Le volume 3 est correspond a un HDD du synology (pas de raid) Et le dossier "docker" est un dossier partagé créé moi meme! 0 Citer
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.