Retour sur "IronWolf Health Management"?

[Oooops!]

Bonsoir,

a priori la manip fonctionne: en 28h comprenant des périodes sans accès extérieur, des périodes avec des transferts de fichiers, DSM ouvert ou pas, le LCC n'a pas bougé sur l'IronWolf 6To du 411+II.

C'est une bonne chose, mais qui ne peut pas être considérée comme LA solution, car écrire sur 4 disques toutes les minutes rien que pour ça c'est pas clean; mais en attendant d'obtenir une solution plus propre et pérenne (j'ai ouvert un ticket chez Syno et chez Seagate pour les IronWolf 8To du 415+), j'aimerais essayer d'améliorer la chose en essayant de voir jusqu'à combien de temps on peut espacer les écritures ".anti-spindown".

Sur internet j'ai trouvé cet exemple de paramétrage de crontab

Toutes les 5 minutes :
 */5 * * * * df >> /tmp/df.log

=> puis-je essayer sans risque de remplacer la 1ère étoile de la ligne "* * * * * root /bin/date > /volume1/.anti-spindown" par "*/2", puis "*/3", etc, pour voir de combien on peut espacer les écritures avant que les têtes se parquent?

[Einsteinium]

Cela ce compte en seconde, si tu augmente, tu as reprendre des lcc

[Lukimaley]

J'ai un problème avec un de mes nouveaux Seagate 4To (ST4000VN008) tout juste deballé.

J'ai remplacé mon disque 3 par un de ces disques, j'ai lancé une reconstruction du volume qui à planté à cause du disque 2...

Problème sur ce nouveau disque 3, le statut SMART indique "En panne" alors que pour le statut IronWolf tout vas bien

Décidément je ne vais pas m'en sortir...

 

Modifié le 19 juin 2017 par Lukimaley

[Oooops!]

Bonjour,

désolé si ce que je vais écrire est inadapté, mais je ne suis pas sûr d'avoir compris ce qui t'arrive car tu parles de problèmes avec le disque 2 et le disque 3, mais d'après tes copies d'écrans, seul le 3 a un souci?

=> si  c'est bien ça, attends d'avoir aussi d'autres avis, mais pour ma part voici ce que j'essaierais si j'étais dans cette situation: puisque tu parles de disques neufs au pluriel, arrêter le Syno(*) et remplacer le disque 3 en cours de reconstruction par un autre nouveau disque ayant subi une "préparation minimum préalable"(**).

(*) normalement le 1812+ permet l'échange à chaud, mais dans le cas présent je ne suis pas sûr que ça soit une bonne idée car tu risquerais d'enlever le disque alors qu'il y a peut-être une opération d'écriture en cours dessus, donc sur-problème?

(**) voici ce que je fais toujours avec mes nouveaux disques avant de les utiliser: une écriture de zéros sur toute la surface sous Linux/DSM, puis un formatage complet sous Windows; si j'ai le temps je lance aussi un scandisk minutieux sous Windows. Ça ne vaut probablement pas l'utilisation de badblocks, mais ça donne quand-même un petit avis sur le disque car il a tourné sur toute sa surface utile au moins 2, voire 3, fois (donc au moins quelques dizaines d'heures).

En ce qui concerne le 4To  en "panne"  sur ta copie d'écran, tu pourrais essayer de le traiter avec le Gestionnaire de disques de Windows: voir s'il y accède, ce qu'il y trouve -tu devrais voir plusieurs partitions (non identifiées par Windows mais reconnues comme présentes), au moins trois, et même plus si tu as un SHR avec des disques de tailles différentes-, et essayer de le formater après avoir supprimé toutes ses partitions.

Sur le fait que Smart et Santé IronWolf montrent des résultats différents, je crois qu'il n'y a que Synology et/ou Seagate qui puissent te répondre.

 

[Lukimaley]

Bonjour,

Merci pour ta réponse, pour essayer d’être un peu plus clair ;)

Je suis embêté depuis plus d'une semaine avec mon NAS.

Tout à commencé par une panne directe sans avertissement du disque 8. J'ai remplacé ce disque 8 (par un 4To IronWolf) et la premier problème: Impossible de reconstruire le volume car des secteurs défectueux sont découvert sur le disque 6.

A chaque tentative de reconstruction du volume -> plantage avec une demande de "Remappage" du disque 6 et redémarrage.

Je décide alors de faire une image de ce disque 6 sur un disque neuf (un 2em 4To IronWolf), je le remonte dans mon NAS et je parviens ensuite à remonter correctement mon volume en intégrant le disque 8.

Le lendemain, je me connecte au NAS -> des secteurs défectueux sont découvert sur les disques 2 et 3 (80 pour le 2 et 700 pour le 3). Je décide de changer le 3 en premier (Par un 3em 4To IronWolf) et lors de la reconstruction du volume -> plantage avec une demande de "Remappage" du disque 2 et redémarrage.

Vu sur un autre post avec Einsteinium, il faudrait un certain nombre de secteurs défectueux pour que le disque ne soit plus au statut "Normal". Je trouve quand même tout cela vraiment étrange.

Des disques apparaissent au statut "normal" avec des secteurs défectueux mais cela bloque la reconstruction du volume...

J'ai lancé actuellement un test SMART étendu sur le disque 2 (d’ailleurs il est également au statut "Echec de partition système"), une fois cela fait, j’espère pouvoir enfin remonter mon volume normalement avec mon disque 3 neuf.

Concernant le disque IronWolf 4To neuf en erreur dans mon précédent post, au lancement de Windows: "SMART Statut bad, Backup and Replace. Je le vois quand même dans mon gestionnaire des disques, je fait un formatage du disque mais à mon avis celui la est bon pour un retour

 

Modifié le 19 juin 2017 par Lukimaley

[Oooops!]

Bonsoir,

merci pour les éclaircissements, c'est effectivement désolant -et curieux- ce qui t'arrive avec cette hécatombe de disques. Je crois que effectivement tu vas devoir faire jouer des retours en garantie ;-(

Juste 2 remarques, petites, pour ne pas trop dériver du thème initial "IronWolf Health Management":
1) je ne pensais pas que la méthode du clonage fonctionnait pour des disques utilisés dans un Syno, c'est bon à savoir (et peut-être à discuter, mais pas ici, plutôt dans un autre topic).
2) je croyais que tous les IronWolf actuels étaient version SC61 (même le 6To, que je viens juste d'acheter, mais qui a été fabriqué en décembre 2016, est déjà en SC61, comme les 8To, achetés il y a 5 semaines mais fabriqués en mars 2017) or tes 4To sont en version SC60; et a priori pas de version SC61 dispo pour eux en téléchargement.

[Oooops!]

Bonjour,

pour en revenir au problème de LCC, j'ai reçu la réponse du support Syno, auquel j'avais pourtant bien décrit la situation => la réponse est en gros: "ça pourrait venir d'une défaillance du disque => faites une vérification approfondie de vos disques avec l'utilitaire constructeur" et une série de lien pour télécharger un tel utilitaire chez différents fabricants.

Je suis conscient que:
1) ils ont peut-être voulu "ratisser large" en fournissant tous ces liens alors que celui de Seagate -que j'avais déjà et qui est facile à trouver directement sur le site- aurait suffi
2) ils disent que c'est un point de départ et on verra ensuite s'il faut aller plus loin
mais je trouve quand même que ça ressemble, sinon à une réponse automatique, du moins à l'application d'une procédure-type sans avoir vraiment lu et pris en compte les spécificités de ma demande (3 disques neufs fabriqués à des dates différentes  affectés du même problème c'est très peu probable, et problème bien connu et décrit sur les forum -au passage, idem chez Qnap-)

[Lukimaley]

J'ai eu la même réponse lorsque je le ai contacté il y a un peu plus d'un an car j'avais sur deux de mes disques (les fameux 5 et 6 en erreurs) des erreurs "end_je_ne_sais_plus_quoi" je pourrai revérifier lorsque j'aurai accès à mon NAS...

donc j'avais passé mes deux disques aux différents tests Seatools qui bien évidemment les détectés intact...

[oliviervdb]

A Lukimaley, c'est un peu hors sujet "Iron wolf Healt Management", mais le faite de trouver des secteurs défectueux quand on fait une reconstruction, est un problème "classique" sur les HD monté en RAID (et pas que sur le Syno, sur tous les sys RAID).

PQ?

Car lors de la reconstruction, le système va devoir relire toutes les données de tous les disques. Et donc ton system va tourner a pleine charge pdt un temps certain, mais surtout, vu que le system va relire toutes les données de tous les disques, c'est a ce moment qu'il pourrait détecter des secteurs qui seraient devenu défectueux suite a de l'usure. Secteurs qui peut être n'ont plus été atteint depuis longtemps (fichiers archivés, ou pas/peu demandés) et qui donc n'avait pas été détectés comme défectueux avant cette reconstruction.  Pour éviter ca, il faut régulièrement que le system relise l'ensemble des fichiers stockés, même si il n'y pas de demande pour ces fichiers par un utilisateur (= faire du "data scrubbing"). Sur les sytem Pro, c'est automatique (Sur le HP Proliant, qd le syst entre en Idle, il se mets a faire du data scrubbing des données automatiquement. Et corrige automatiquement les erreurs, voir prévient l'admin si problème, ) Sur les syno, depuis DSM6.1 (je crois), il est possible de planifier un tache pour ca. Pour les version antérieur, il faut le lancer manuellement (meme si le syst préviens et le propose 1 fois par mois il me semble, sur les sys monté en RAID).

Ca permet une bonne flexibilité p/r a la criticité et l'utilisation du système. Si utilisation critique, l'admin peut lancer automatiquement et régulièrement des taches de data scrubbing, si c'est pas le cas, il peut le lancer a intervalle plus long, et comme ca "ménager sa monture". car bien entendu, faire du data scrubbing, utilise les disques, et d'une façon, les "usent" aussi. D’où l’intérêt de trouver un balance entre la criticité et le risque.

Perso je lance ce "nettoyage" comme appeler par synology dans le gestionnaire de disque, 1 fois / mois.

[PierU]

Le 25/06/2017 à 17:14, oliviervdb a dit :

Perso je lance ce "nettoyage" comme appeler par synology dans le gestionnaire de disque, 1 fois / mois.

Je remonte ce vieux topic : où se trouve cette option de "nettoyage" dans DSM ? Je ne trouve pas...

[oracle7]

@PierU

Bonjour,

Regardes ici : "Gestionnaire de stockage / Groupe de stockage / Nettoyage des données "

Cordialement

oracle7😉

[PierU]

@oracle7 Je n'ai rien de tel à cet endroit (ni dans le sous menu "Action" ni dans l'onglet "Configurations") : https://i.imgur.com/wF53joM.png

[oracle7]

@PierU

Bonjour,

Je pense que cela doit être lié à ton type de système de fichiers - ext4 ou au moèle de NAS -"J" (mais je peux le tromper), un spécialiste comme @maxou56 s'il passe par ici, pourrait certainement te dire ce qu'il en est effectivement.

D'ailleurs du coup je m'aperçois qu'il faudrait que le le fasse préventivement.

Cordialement

oracle7😉

Modifié le 5 juillet 2021 par oracle7

[PierU]

En effet, en ext4 ET avec moins de 3 disques il n'y a pas : https://www.synology.com/fr-fr/knowledgebase/DSMUC/help/DSMUC/StorageManager/storage_pool_data_scrubbing

[PierU]

Question complémentaire : que fait le test SMART étendu ? Vu le temps qu'il dure, est-ce que justement il ne tente pas de lire tous les secteurs ?

[oracle7]

@PierU

Bonjour,

Ah oui c'est toujours très long, pour moi, il contrôle tous les secteurs (mais je peux me tromper).

Sinon regardes cet article il est intéressant.

Cordialement

oracle7😉