XigmaNAS

Bonjour,

Sur une machine que je suis en train d'upgrader j'ai des disques qui passent en statut "Removed" régulièrement.

Le soucis c'est que quand je dois changer un disque pour upgrader le pool, cela s'est déjà produit plusieurs fois pendant le "Resilvering". Et ça c'est plutôt mauvais ... surtout quand il y en a 3 ou 4 en même temps (mais je ne sais pas sil il sont passé sur "Removed" exactement au même moment : y a t-il un moyen de le savoir : journal de logs ou autres ? )

Au début je me suis dis que les disques pouvaient êtres mal mis dans le rack alors je les débranchaient-rebranchaient à froid. Mais je me suis aperçu qu'il simple redémarrage de la machine suffisait à les faire repasser sur "Online", donc j'ai mis de côté ce problème hardware !

Cela arrive aussi bien quand le contrôleur est le chipset de la carte que sur d'autres contrôleurs internes à la carte mère, ou externes à la carte mère.

Avez vous des idées de pistes car je ne vois plus ou chercher.

Merci

Il faudrait connaître le modèle des disques d'une part et vérifier dans la gestion des disques en cause ces points:

Délai de mise en veille du disque :Toujours actif
Gestion d'énergie avancée : Désactivé
Niveau acoustique : Désactivé

Les disques sont différents modèles de la marque Seagate et tant la gestion de la mise en veille, de l'économie d’énergie des disques et du niveau acoustique de ceux ci est désactivé : de toute façons ces paramètres se désactive à chaque fois que l'on réimporte les disques et comme je le fais à la fin du resilvering de chaque remplacement de disque.

Comme je suis en resilvering 24h/24h le temps de remplacer mes disques je n'ai aucun intérêt à tous les reparamétrer apres chaque réimportation, je le ferait quand j'aurai remplacé tous les disques, ils n'ont pas vraiment le temps de se reposer depuis quelques jours ...

Une autre piste ?

Pour info cela fais quelques heures qu'ils tournent au repos (petites requêtes de recherches ou lecture de fichiers de temps à autres) et aucun disque ne pose n'est en statut "Removed" (c'était pareil dans mes souvenirs avant l'upgrade alors que la mise en veille après 20 minutes était activée sur tous les disques). J'ai l'impression que c'est plus pendant le resilvering que cela apparait ! Est ce dû au travail intensif de ceux ci ? Aucun ne dépasse les 35°C et c'est même plutôt entre 30 et 33 selon les disques.

Vraiment je ne vois pas et c'est aléatoire. J'ai eu des resilvering de disques qui ont duré plus de 24 heures sans qu'aucun disque ne passe en statut "Removed"

Merci

"de toute façons ces paramètres se désactive à chaque fois que l'on réimporte les disques et comme je le fais à la fin du resilvering de chaque remplacement de disque."

Donc si je comprends bien vous lancez un zpool replace sans ajouter le nouveau disque dans le gestionnaire préalablement ?

Oui. Et je ne trouve pas cela logique non plus !

J'ai essayé d'importer le nouveau disque avant de lancer le "replace" mais si par exemple je remplace l'ada6 par l'ada6 j'ai un message d'erreur (je ne me souvient plus exactement mais je peux réessayer si cela vous intéresse) et le resilvering ne se lance pas.

Message que je n'ai pas si je fais d'abord le "replace" ada6 par ada6, puis j'attends la fin du "resilvering" et ensuite j'importe les disques.

Au final j'ai un RAID-Z2 complètement fonctionnel et bien ONLINE : actuellement 24 heures qu'il tourne à ne rien faire (hormis quelques échanges de données) sans problème : il n'y a que quand je lance un srub ou un resilvering du fait du remplacement d'un disque que le problème apparait aléatoirement.

Merci de votre aide

Le message est normal, car "l'ancien" ada6 n'est pas "offline", zpool replace sous-entend des identités de disque différentes.

zpool offline ada6 (ancien disque )
il devient par exemple 10722503524616512853 (à copier obligatoirement au cas ou cette information disparaitrait)
remplacement physique
déclaration du nouveau disque
zpool replace votrepool 10722503524616512853 ada6

puis zpool online -e ada6 s'il est plus grand que l'ancien et que autoexpand n'est pas activé.

Par contre si vous avez un disque correctement déclaré sur un slot sata de libre vous pouvez faire un "replace" directement

Par contre si vous avez un disque correctement déclaré sur un slot sata de libre vous pouvez faire un "replace" directement

Je ne comprend plus : dans un autre sujet vous me disiez le contraire :

Uniquement possible en "mirror" à partir du troisième disque.

Non c'était pour avoir un disque similaire sans passer en degraded pour le pool.
Deux en miroir on ne peut pas faire de "detach" car réplication insuffisante
Deux en miroir on peut faire un "add" donc trois disques identiques (pour ce qui est des données)
Trois en miroir on peut faire un "detach) car réplication suffisante
Dans cette manip on peut augmenter la taille des disques sans passer en degraded.

OK je vais tenter de changer les disques un a un en les mettant sur un slot libre. C'est moins risqué.

Par contre j'ai eu quelques erreurs de checksums sur plusieurs disques passés en "removed" depuis ce fichu dernier disque pour lequel je n'ai pas réussi à aller jusqu'au bout du resilvering.

J'ai essayé de lancer un scrub plusieurs fois et je n'arrive pas à aller au bout de celui ci sans avoir un ou des autres disques qui passent en "removed" pendant l'opération.

Est ce nécessaire de lancer un scrub si j'ai des erreurs de checksum avant de poursuivre le changement des disques pas encore upgradés. Je pense (peut être à tort) que le checksum me ferait repartir sur une meilleure base pour les remplacements des disques suivants.

Merci

tout à fait il faut un pool "propre" avant de changer un disque non défaillant

Comment faire alors si j'ai toujours des disques qui passent sur removed pendant le scrub ?

Pensez vous que la charge sur les disques puisse poser problème pendant le scrub ?

Merci

Pensez vous que la charge sur les disques puisse poser problème pendant le scrub ?

Jamais vu ça.

Quelque chose à certainement mal évolué sur votre NAS à un moment c'est soit matériel soit logiciel mais il faut stabiliser la situation avant de continuer.

Bonjour,

J'ai déjà eu des petits soucis de ce genre (lors de montage ésotériques à "tendance bancale") et j'ai une petite astuce qui des fois remets les pendules à l'heure, l'export et le ré-import de pools.
Faudrait essayer, quand tout est bon, d'exporter le pool, puis de le ré-importer.

Par exemple, je me suis énervé sur un pool qui indiquait un état et avec une certaine configuration (fichiers/répertoires), je me suis rendu compte, que tout était revenu en ordre après une réimportation.

Sinon, vous avez des messages sur un zpool status -v ?

J'avais des erreurs de checksums qui apparaissaient après une ou deux heures de fonctionnement et sur les disques qui étaient passés au statut "removed".

C'est la raison pour laquelle je voulais lancer un "scrub" avant de poursuivre les remplacements de disques : histoire de partir sur une base stable sans erreurs pour faire les prochains "resilvering".

Le soucis c'est qu'après quelques heures de "scrub", j'ai toujours au moins deux disques voir 3 (c'est variable sur 5-6 disques sur des contrôleurs différents) qui passent en statut "removed". Donc là j'arrête tout immédiatement et je relance la machine et plus de soucis pendant quelques heures, puis l'apparition à nouveau des erreurs après quelques heures sur les disques passés précédemment en "removed" et si je relance le "scrub", au bout de quelques heures : disques en "removed" ... bref une impasse.

Je suis en train de tester les disques posant problème en les branchant en USB : c'est plus long pour le scrub mais cela fonctionne, on verra dans quelques dizaines d'heures à la fois si cela tient bon, si le scrub à pu se terminer et j'en tirerai les conclusions : problème contrôleurs, incompatibilité disques/contrôleurs dans le temps, on verra bien mais ca commence à me saouler tout ce temps perdu

Vous avez combien de mémoire ?

Car je me demande si en faisant un scrub, vous ne dépasseriez pas le maximum de mémoire pour la taille de l'ARC

J'avais ce genre de problème à une époque.
Vous avez des gros fichiers, beaucoup (en nombre) ?

En effet pour la RAM je suis bien en dessous de la taille de nombreux fichiers qui est souvent supérieure au moins du double voir plus. 10-20 Go certains fichiers et nombreux 4-10Go contre 6Go de RAM.

Pourtant quand je regarde le taux d'utilisation de celle ci dans le menu système du WebGUI je ne dépasse guère de 15%.

Je sais bien qu'il faut 1Go par To mais je sais aussi que c'est pour un usage intensif : ce que je ne fais pas : c'est juste du stockage de vidéos de box internet.

Cela pourrait-il quand même venir de là ?

Je vais quand même essayer de persévérer avec quelques disques en USB pour voir si cela résous mon problème.

Le pb que j'avais eu à une époque me faisais rebooter mon nas (mais depuis, certains réglage sont "mieux fait" et cela ne pose plus de soucis).

La notion de 1Go par To, est un calcul qui n'est pas vraiment exact, ZFS fonctionne en cascade, il lit ses infos et les embarquent en mémoire et dans son cache si il en a un (le SSD par exemple), ensuite si iln'a plus de place, il vire ce qui ne sert pas et ramène de nouvelles données (il en profite aussi pour tenir une table de cache et de cache fantôme (un cache des habitudes du cache).
Quand les données partent de la mémoire et du cache (si il y en a un), elles seront, au besoin, relues sur le pool.

Le hic, c'est que si le fichier est très volumineux, l'arbre (index ZFS) qui le représente doit être intégralement dans la mémoire vive, si il ne peut pas, c'est les ennuis, car c'est le strict minimum.
Il est tout a fait possible aussi que lors d'un scrub, il y aie une grosse utilisation de la mémoire et qu'elle mette un temps pour être libérée et que l'arbre ne puisse pas tenir en mémoire.

Question pour confirmer cela, est-ce que sans scrub, ZFS fonctionne correctement ?

Scrub peut être lancé en ligne de commande et peut aussi être arrêté, il serait intéressant de lancer le scrub jusqu'à 25% du pool et de l'arrêter pour voir si le problème survient, et, si c'est bon, le relancer de 0 jusqu'à de nouveau 25%, (pour faire un volume 50% du pool mais que sur une longueur de 25%)
J'aimerais en fait, savoir ou se situe la limite, mais bon, c'est une piste.

Sinon, quel est le taux d'occupation du pool ?

Pour les disques en USB, vous avez du courage, pour moi c'est une catastrophe l'USB, mais c'est mon avis

J'ai essayé d'arrêter le scrub mais je ne sais pas comment le faire reprendre ou il s'est arrêté ! Je suis preneur d'info. Sur les copies d'écrans que j'ai fait, à 35% j'avais déjà des disques en statut "removed".

En effet comme je le précisait en dehors du scrub pas de soucis ! Mais pourquoi des disques "removed" je trouve que cela n'est pas logique ! Pourquoi pas un message d'erreur ?

Actuellement le pool scrub a 150 Mo/s c'est pas si mal avec 4 disques sur deux ports USB seulement : je n'avais qu'un peu plus du double en tout SATA ! Et puis ce n'est que provisoire

Le Pool est à 98% il reste 80 Go de libre et il y a quasiment que des fichiers ts ou m2ts allant de 500 Mo à 20 Go issu de FreeBox mais des milliers beaucoup de temps passé à programmer

Pendant le scub le taux d'utilisation de la RAM reste à 15% je n'ai jamais vu plus de 20-25% d'utilisé et c'était pendant le remplissage pendant des heures

Merci

scrub et resilvering sont exclusifs avec la priorité à resilvering.
scrub ne consomme pas de mémoire par contre pour être transparent vis à vis des i/o scrub recopie sur le disque tous les blocs dont le checksum est mauvais afin de les traiter puis de les écrire et c'est là que vos 98% d'occupation m'inquiètent.

Oui mais 98% de 2To c'est pas pareil que 16To ? Ça laisse quand même pas mal de marge de manœuvre ?

Sinon il faudrait descendre à quelle limite ?

Merci.

Tout dépend du nombre de blocs erronés.

Je comprends, et il y a un moyen de voir le taux d'utilisation du disque changer au fur et a mesure qu'il répare des blocs ? Afin de voir si l'on est proche de la limite ? Une sorte de moniteur d'activité mais pour l'usage du disque ?

Mais je me pose une question, il ne fait qu'un seul fichier à la fois donc si mon plus gros fichier fait 20 Go, en théorie 20 Go avec une grosse marge du genre 100 Go devrait suffire ? Non ?

ça a fonctionné en usb ?

Pour l'instant le scrub tourne en USB ce matin il était aux alentour des 15%, encore un ou deux jours de patience ... mère de sûreté j'ai envie de dire

Bonjour,

Je voulais mettre l'autre fois qu'un pool ne doit pas dépasser 90 à 95%, je ne sais plus ou j'ai vu çà mais ça me semble un peu logique (même si ce sont de % et que sur une petit taille ou une grosse, les choses sont différentes).

Avez-vous essayé de voir ce que donne la commande zpool history, est-ce que le remove s'y trouve ? (par contre, je ne sais pas si c'est l'historique de ZFS ou de l'admin).

Est-ce qu'il serait possible de prendre quelques gros fichiers et de les mettre hors du pool ? de façon de faire une taille inférieure à 90% et de relancer les opérations ?

Sinon, que donne un: sysctl -a | grep vm.kmem_size_max ?

Pour l'USB, oui, ça marche, et mieux maintenant avec les dernière versions, je suis d'accord, mais sur des choses simples.

Pour vos fichiers ts et m2ts, vous les recompressés ? j'ai ai aussi et j'ai diminué par 3 ou 4 le volume des données en utilisant avidemux.
l

Chez Solaris on conseillait de ne pas dépasser 85% mais cela dépend de la taille des blocs et de la dégradation des données pour réaliser un scrub .
De toute façon la fragmentation augmente entre 70% et 90% causant des pertes de vitesse.

Ce qui m'étonne vraiment, c'est que les disques passent en removed !

Pour la taille, je devrais pas le dire ... mais ... je suis déjà monté à 99,99% sur un entrelacement de 3 disques de 2To (soit 6To), sur une toute petite carte-mère fanless et avec 4Go de RAM, et, je n'avais pas de soucis (bon, je n'ai pas lancé de scrub non plus), mais tout çà pour dire qu'on peut des fois aller loin ... enfin "proche" des limites

Ils passent en removed quand le système ne peut plus écrire dessus et quand le système redémarre, ZFS qui stocke le résultat du scrub au fil de l'eau, se contente de nettoyer les blocs temporaires ce qui fait que le disque revient online.

donc, on pourrait imaginer des blocs mis à l'écart par ZFS lors du scrub ? au point de ne plus avoir de place ? donc blocage et ensuite au redémarrage tout redevient bon.

Donc, si on déplace de gros fichiers (ailleurs) pour avoir plus de place, on devrait améliorer les choses, non ?

Avez-vous essayé de voir ce que donne la commande zpool history, est-ce que le remove s'y trouve ?

Pas de trace de remove depuis la création du NAS et du Pool. Pour admin je ne sais pas comment faire.

Est-ce qu'il serait possible de prendre quelques gros fichiers et de les mettre hors du pool ? de façon de faire une taille inférieure à 90% et de relancer les opérations ?

C'est ce que je compte faire si j'essuie toujours des removed en USB.

Sinon, que donne un: sysctl -a | grep vm.kmem_size_max ?

vm.kmem_size_max: 329853485875

Pour vos fichiers ts et m2ts, vous les recompressés ? j'ai ai aussi et j'ai diminué par 3 ou 4 le volume des données en utilisant avidemux.

Je dois me lancer mais le but étant de couper les pub et tronquer les fichiers, je ne sais pas quoi utiliser comme soft qui sache le faire sur le H.264 des fluxs ADSL. Je suis preneur d'infos si vous arrivez