This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

firlin

[TUTO] Préparation des disques avec Badblocks

Messages recommandés

@lucas3d merci pour ce retour.

Peux tu confirmer les réglages (pattern) utilisés ?

NAS (modèle et version DSM), quantité ram interne, commande ?

--

Pour ma part, je viens de lancer un badblocks depuis un live DVD de CentOS avec seulement 2 Go de ram … sur 2 disques de 8 To en même temps.

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 4 heures, apossium a dit :

Peux tu confirmer les réglages (pattern) utilisés ?
NAS (modèle et version DSM), quantité ram interne, commande ?

Je l'ai fait sur mon Synology directement, un DS918+ avec 4 Go de ram.

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

Par conte, le test avec mes WD green 2 To est beaucoup plus lent (25% en 100 heures!)...

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 19 heures, lucas3d a dit :

Je l'ai fait sur mon Synology directement, un DS918+ avec 4 Go de ram.

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

Par conte, le test avec mes WD green 2 To est beaucoup plus lent (25% en 100 heures!)...

 

OK merci, c'est une vérification dite non destructive et simple passe (paramètre -n), adapté par ex. aux opérations de maintenance préventive.

De faite c'est 4 fois plus rapide qu'avec le paramètre -w qui lui comporte 4 passes … lui plus adapté au vérif. de nouveaux disques.

Citation

Default is an extensive test with four passes using four different patterns: 0xaa (10101010), 0x55 (01010101), 0xff (11111111) and 0x00 (00000000)

Donc attention, la vérification que tu as réalisée est pertinente mais reste moins profonde (je ne discute pas le choix).

8 To c'est long, je suis en train d'en faire l'expérience :(

 

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Le test non destructif est plus que suffisant et bien meilleur que tous les test constructeurs... là tu fatigues juste tes disques pour rien... et tu leurs crament 4 cycles d’écritures pour rien...

Partager ce message


Lien à poster
Partager sur d’autres sites

non, je ne suis pas d'accord.

La vérif. non destructive ne vérifie pas avec certitude chaque bit …

Dans le cas du test destructif, on a 2 changements d'état (4 x écritures + 4 x lectures ) obligatoires.

Dans le cas du test non destructif, si je comprends bien puisque c'est un pattern aléatoire …

un bit peut être à 0, écrit à 0, puis remis à 0. Donc on ne sait pas si il peut être écrit …

Ceci dit chacun fait ce qu'il veut …

Les disques qui sont intégrés en prod. doivent être vérifiés de mon côté, cela pose trop de problème si aller retour.

Si il existe une manière moins contraignante de vérifier je suis preneur (augmentation taille mémoire, arrêt après phase 3 par ex. = 1 changement état garanti).

Mais la cet essai non destructif ne me satisfait/convient pas (tel que je le comprends).

 

Modifié par apossium

Partager ce message


Lien à poster
Partager sur d’autres sites

@Einsteinium : tout ce que je dis / affirme se repose sur des info. disponibles ici : https://wiki.archlinux.org/index.php/badblocks

Maintenant je veux bien apprendre / comprendre. Me renvoyer vers des lectures sans indications, j'accepte volontiers un lien ou deux,

parce que ce sont mes recherches précédentes qui me permettent de prendre cette position pour les 4 pattern.

nota : surtout si je passe 8 jours à vérifier un disque alors que cela ne sert strictement à rien …

Modifié par apossium

Partager ce message


Lien à poster
Partager sur d’autres sites

@Einsteinium et @apossium : vous avez tous les 2 raison, ne vous fâchez pas :lol:

  • -n va effectivement moins loin que -w mais convient à la plupart des cas
    • il est possible que sur la durée de vie du disque certain blocs en erreurs provoquent des problèmes
    • mais il est aussi possible de cramer des données pendant le test
    • => attention aux sauvegardes
  • pour une machine sur laquelle on peut difficilement intervenir, le -w peut s'avérer utile mais il fatigue aussi nettement plus les disques
    • c'est 16 cycles qui sont effectués (4x4)
    • et la réserve de blocs sera nettement plus entamée (y compris pour des blocs qui n'auraient jamais été utilisés)
    • =>il y aura moins de temps entre le début des problème et la mort du disque => il faudra plus superviser ces disques

C'est donc une question de besoins avant tout

ps : le facteur temps peut aussi rentrer en ligne de compte

Partager ce message


Lien à poster
Partager sur d’autres sites

@Fenrir : merci pour ces précisions.

L'objectif ici est de valider des disques durs neufs avant mise en production dans un serveur (et tenter de garantir un fonctionnement même si c'est prétentieux).

Si des secteurs défectueux sont observés (en nombre important) sur un disque neuf (le but principal de l'opération).

nota : je ne sais pas définir "important" si vous avez des info. …

Ce disque ne sera pas utilisé (disque réparé ou non).

---

Par ailleurs, je ne mesure / saisi pas la logique de la fatigue disque évoquée …

Si un disque neuf ne supporte pas 4 pattern alors qu'il est neuf, que va t il dire ou faire quand il sera en prod. ? j'ai pas envie de travailler ? :D

Combien de cycle peut encaisser un même secteur/bloc en R/W ? A part les facteurs MTBF, AFR, Wear ou load/unload cycle, je n'ai pas trouvé d'info la dessus …

Après recherches, les info concernant les HDD ne sont plus mis en avant (le SSD a tout remplacé chez Google :D). Pas simple, l'utilisation du paramètre - est requis :(

--

Le paramètre -c augmente l'efficacité de badblocks. De quelle ordre de grandeur … essai à faire … mais pas avec mes 8 To :D

 

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 1 minute, apossium a dit :

nota : je ne sais pas définir "important" si vous avez des info. …

C'est une question de moyen VS importance des données. Pour ma part :

  • 1 bloc en erreur (non corrigé) => remplacement du disque programmé asap
  • réallocation sur 2 chiffres => idem
il y a 4 minutes, apossium a dit :

Si un disque neuf ne supporte pas 4 pattern alors qu'il est neuf, que va t il dire ou faire quand il sera en prod. ? j'ai pas envie de travailler ? :D

Ce n'est pas tant les 16 cycles que l'endroit où ils sont fait qui peut poser problème.

En usage "normal", on n'écrit JAMAIS sur toute la surface d'un disque, ce qui laisse plein de place pour la réallocation des blocs/secteurs défectueux par le "système" lors des phases de scrubbing (en plus de la réallocation gérée par le disque lui même) et diminue d'autant les chances de tomber sur un problème.

En faisant un test destructif, toute la surface du disque y passe et le nombre de réallocation (gérée par le disque, pas par le système) peut très vite augmenter pour corriger des erreurs sur des zones où tu n'aurais de toute manière jamais écrit.

En passant, -w implique qu'il n'y a rien sur le disque (même pas DSM dans le cas d'un syno), donc ce n'est pas toujours possible de s'en servir.

il y a 23 minutes, apossium a dit :

Combien de cycle peut encaisser un même secteur/bloc en R/W ?

Plus que la durée de vie de la mécanique du disque ne le permet.

-----

Et pour le -c, ça peut augmenter la vitesse, la réduire mais aussi augmenter ou réduire la fiabilité du test => si tu veux jouer avec cette option il va falloir connaitre précisément toutes les spécifications de ton disque (taille des blocs, tampon, blocs par cylindre, nombre de plateau, ...) et sortir la règle à calcul. Par défaut c'est 64 blocs en parallèle avec 1024B/bloc (ton lien date de 2002, il n'est plus du tout adapté). Sur les disques actuels, un bloc c'est généralement 4096B (c'est le -b dans les options)

Partager ce message


Lien à poster
Partager sur d’autres sites

@Fenrir : merci pour ton temps, je comprends mieux la logique …

Un des facteurs à surveiller serait donc la taille du disque adressable (puisque si elle diminue c'est que le firmware alloué / déplacé / invalidé des secteurs.

Je comprends aussi qu'un disque ne peut être parfait même si après les tests on obtient zero erreurs.

Il y a des mécanismes sous-jacents automatique que l'on ne maitrise pas …

Merci encore à vous deux !

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 10 heures, apossium a dit :

Un des facteurs à surveiller serait donc la taille du disque adressable (puisque si elle diminue c'est que le firmware système alloué / déplacé / invalidé des secteurs.

Si c'est le firmware qui le fait il pioche dans sa réserve perso (qui n'est pas visible), mais dans dans tous les cas on parle ici que blocs, donc les variations sont minuscules.

Partager ce message


Lien à poster
Partager sur d’autres sites

Je veux pas paraitre impertinent mais la on dérive du tutos original Messieurs

Le plus simple c'est d’ouvrir un nouveau post, pour parler des caractéristique de badblock

 

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 47 minutes, Fenrir a dit :

Si c'est le firmware qui le fait il pioche dans sa réserve perso (qui n'est pas visible), mais dans dans tous les cas on parle ici que blocs, donc les variations sont minuscules.

Je ne reproche rien à ce mécanisme (et vu ce que représente un bloc ie. 4096 bit).

Je dis simplement que le nombre de bloc adressable ce serait un moyen indirect de vérifier le nombre de bloc défectueux et l'évolution de la panne.

Peut être que SMART les enregistre d'ailleurs ? Ceci dit si on enregistre/filme puis compare la valeur du nombre de blocs adressables (depuis début puis périodiquement).

On peut constater une dégradation.

--

Je viens enfin d'intégrer vos remarques …

En écrivant des 0 et 1 sur un bloc de manière aléatoire, si une partie du secteur est défectueuse, il y aura certainement plus d'un "bit" concerné dans le lot de 4096 …

et donc on ne passe pas vraiment à côté d'un "zone défectueuse" (je suppose que ce sont des zones défectueuse et non un bit seul) en écrivant de l'aléatoire …

Alors que dans le cas de l'écriture avec 4 pattern (forcer l'écriture à plusieurs reprises), on détecte les moindres défauts.

C'est ce que tt le monde a évoqué (pas suffisamment explicite par écrit certes) … avec le recul, je comprends mieux … désolé !

Et puis j'ai lu qu'il y a une somme de contrôle après chaque bloc donc si il a été mal écrit, le bloc est invalidé à la première relecture je pense.

---

Oui si vous voulez spliter pas de pb. Mais cela concerne quand même badblocks (on du moins un disque) et son fonctionnement.

Ces échanges sont pertinents ! Et puis on a presque fini :D

Merci encore.

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour,

voici un rapide retour d'un essai :

sur un disque 8 To WD Red, essai non destructif (sur un banc d'essai CentOS last, disque interne SATA) :

sudo badblocks -nsv -b 4096 -c 5000 /dev/sdb > /home/liveuser/Desktop/sdb.log 2<&1

67:25:15 elapsed. (0/0/0 errors)100.00% done, 67:25:16 elapsed. (0/0/0 errors)done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant