XigmaNAS

Bonjour,

Sur un premier NAS en RAID-Z2 (config matérielle différente du second dont je parlerai ci après) j'avais constaté que de temps à autre, lorsque je demande à éteindre ou a redémarrer celui ci (par l'interface ou directement avec le menu du clavier qui est connecté en permanence au NAS (choix 7 et 8 de mémoire)), celui ci ne s'éteind ou ne redémarre pas.

J'ai alors l'affichage suivant sur l'écran du NAS :

System going down IMMEDIATELY

Stopping lighttpd
Waiting for PIDS: 2143.
Stopping cron.
Stopping powerd.
Waiting for PIDS: 1897.
Stoppping afp
Waiting for PIDS: 2711.
Stoppping devd
Waiting for PIDS: 1588.
Writing entropy file:.
90 second watchdog timeout expired. Shutdown terminated.
Tue May 28 00:41:23 CEST 2013
May 28 00:41:23 init: some processes would not die; ps axl advised
Waiting (max 60 seconds) for system process 'vnlru' to stop...done
Waiting (max 60 seconds) for system process 'bufdaemon' to stop...done
Waiting (max 60 seconds) for system process 'syncer' to stop...done
Syncing disks, vnodes remaining...0 done
All buffers synced


Etant donné la quantité de données q'il y a dessus j'ai évité d'y toucher et me suis dit que lorsque j'en constituerai un second j'essaierai de voir avant de le remplir si le problème se reproduit avant de mettre des données dessus : et voilà c'est arrivé, le même phénomène est apparu sur le second NAS !!!

Par expérience, sur le premier NAS le phénomène se produit essentiellement lorsque j'ai navigué dans le NAS ou ajouté/déplacé des fichiers. Si je force le reboot de celui ci après il s'éteint sans soucis (sauf si à nouveau je refais des ajouts/déplacement ou exploration de fichiers dessus mais il arrive que je sois surpris que cela ne lui pose pas de problème... )

Sur le second, le NAS est vide il est juste constitué d'un RAID-Z1 et m'a déjà provoqué ce dysfontionnement en y ayant pas touché mais après quelque heures de fonctionnement.

Je me dis donc que cela ne vient peut être pas du contenu mais du paramétrage ou d'autre chose, oui mais quoi, puisque j'ai le même soucis sur deux matériels complètements différents ?

Le second a été fait directement avec la dernière 9.1.0.1.724 sur CD

Merci pour votre aide

Personne n'a jamais été confronté à cette situation ?

Merci

Bonsoir,

Pouvez-vous tester si cela se produit sur un Nas4Free avec une configuration "usine" (menu "Système|Réglage d'origine") ou avec le moins de configuration possible (seulement l'adresse IP) ? Vous pouvez ne déclarer aucun disque même avec les disques physiquement montés dans le PC juste pour le test.

Cordialement.

Je vais essayer mais comme je l'ai dit tant que je n'accède à aucune donnée il y a peu de risque d'avoir le soucis, d'ailleurs de mémoire il ne me semble pas l'avoir déjà vu ! Et depuis que j'ai constaté ce soucis je suis un peu aux aguets pour essayer de savoir à partir de quel stade le problème apparaît, mais comme il est aléatoire ...

Je vais essayer quand même mais je n'y crois pas.

Bonjour,

Combien de mémoire avez-vous sur vos nas ?
Quelle taille font vos fichiers que vous déplacez ou ajoutez ?

En effet, je ne respecte pas la règle 1Go pour 1To : l'un d'entre eux est un RAID-Z2 de 10 disques de 2 To avec 6 Go de RAM

L'autre est un RAID-Z1 avec 5 disques de 2 To avec seulement 2 Go (honte à moi il me semblait qu'il était pourvu de 4 Go )

Les fichiers que je transfère font régulièrement plus de 4 Go : 2 heures de MPEG-4 d'une FreeBox en HD ça pèse ... Quand ce n'est pas 4h de MPEG-2 qui font 8 Go voir plus ...

Pourtant en fonctionnement cela ne pose aucun soucis, le NAS ne semble pas prendre plus de 20-25 % même lors de long transfert : plusieurs centaines de gigas composés de fichiers de plusieurs gigas.

C'est d'ailleurs à la contruction du premier NAS la raison pour laquelle je me suis dis que je n'ajouterais pas de mémoire, avec celle en plus que j'ai vu sur plein d'autres forums disant que la quantité pouvait être revue à la baisse si on avait une faible sollicitation du NAS ... Grosso modo mis à part quand je le rempli il n'y a jamais guerre plus d'un seul fichier qui est lu à la fois par un XBMC ou un Raspberry Pi. Pas de quoi mettre le NAS à genou ...

Mais il faut peut être simplement chercher dans cette voie.

Je me demande si je ne devrais pas essayer de transférer les disques du petit NAS dans la plus grosse config matérielle du gros NAS pour tester pendant quelques jours ...

Qu'en pensez vous ?

Il est possible que votre problème est dû à la mémoire.

Cela ressemble a un problème que j'ai déja eu ici:
viewtopic.php?f=35&t=2705
message du 9 Mars 2013 à 12:32 (mon expérience)
Toutefois, le nas ayant évolué, il ne reboote pas mais a un comportement étrange.

Ce n'est pas un "problème en soi", il suffit d'appliquer les commandes et de régler ZFS "au mieux".

Je pense que l'explication est la suivante (je peux me tromper).
La gestion mémoire du ZIL grandit en fonction de la taille des fichiers qui y passent (cache de l'index). Sa taille n'est pas illimitée, de plus, les infos restent dans le ZIL un certain temps. Ce temps est nécessaire au "vidage" des différents caches des disques durs notamment (les disques durs possèdent du cache). Il ne faut pas oublier que ZFS est insensible aux coupures de courant.
Selon Oracle (les gérants de ZFS), une perte de données sur une coupure de courant est impossible ! Il faut savoir que la validité de l'information écrite sur le disque ne se fait que sur un seul bit, c'est à dire qu'un seul bit peut valider, ou non, l'écriture de 1 ou 20 Go de données d'un coup.
Ce bit, n'est pas validé immédiatement, mais après un certain temps. Or, si pendant ce temps-là les données continuent de passer par le ZIL, elles vont remplir toute la mémoire et le système devient instable car la taille maxi en usine est réglé beaucoup trop haute.
La rêgle d'or du 1Go par To est une "rêgle statistique", en gros, on dit que généralement avec ça ... ça va bien le faire pour une utilisation courante, cela reste une gestion "au mieux".
Pour éviter ces problèmes, on peut rêgler la mémoire de façon a ce que ZFS tiennent compte de la taille du volume de données "en cours".
Un système ZFS peut parfaitement fonctionner avec 4Go avec 12To de disques, de même qu'un système ZFS pourra avoir des soucis avec fichier de 20Go sur un système ayant 16Go de RAM pour 1To de disques !. En fait c'est complexe, car pour le mettre en défaut, il faut d'autres éléments réunis (j'arrivais a planter mon ZFS avec un simple chmod ... sur un million de fichier). C'est pour cela que cette notion de RAM n'est pas facile a appréhender sur ZFS. c'est pour cela aussi que l'on pense que c'est aléatoire, moi j'ai eu la chance de pouvoir mettre ce défaut et le reproduire de façon systématique (j'ai mis 2 ans).

Donc, dans votre cas, je dirais qu'il faut régler ZFS, c'est vraiment pas compliqué, le plus dur est le ro a passer en rw sur le fichier /cf/boot/loader.conf (dans le cas d'une CF)

J'essaie de digérer tout cela mais pas évident. Pour m'aider un peu qu'est ce que le ZIL ?

Meric

Dans un système de fichier classique, les données sont écrites sur le disque et certaines informations sont écrites dans une partie appelée "journalisation". Ce système est bien mais des données peuvent sembler être journalisées mais elles seront encore dans le cache du disque dur et donc non présente physiquement sur le disque.
Cela marche très bien avec un certains nombre de données mais lorsque l'on arrive a un certain "niveau" cela peut devenir dangereux.

Les gens qui ont pondu ZFS ont imaginé un système qui doit être insensible a ce genre de défaillance. Ils ont donc élaborés la gestion de ZFS sous forme de couche, ces couches servent surtout de "cache disque".
Par priorité, la RAM est utilisée, après c'est un SSD (si il y en a un bien sûr!) et ensuite le disque (log ou le disque normal).
La gestion des couches de "cache disque" de ZFS est géré par un algorythme qui s'appelle l'ARC.
si tu tapes (en root):
sysctl -a | grep zfs | grep vfs.zfs.arc
cela te donnera les valeurs en cours de l'ARC
L'ARC possède des données un peu partout, en RAM et sur les disques, ZFS gère cela en utilisant au mieux la rapidité des éléments présents. Ceci constitue le "moteur de ZFS".
Ensuite, pour le cas des écritures, on trouve une zone, qui s'appelle ZIL "Zone Intented Log".
Quand il faut écrire des données dans le pool, ZFS va -par l'intermédiaire de l'ARC- créer une zone ou il va mettre tous "ses petits" dedans, il va conscencieusement faire le travail mais celui sera validé plus tard.
Lorsque toutes les donnéees sont écrites (par exemple un fichier vient d'être copié sur le nas), ZFS va vérifier que tout ce "petit monde" est prêt a être validé. Si une coupure de courant se produit avant cette validation, cela ne pose pas de pb a ZFS, celui sait au redémarrage que la ZIL contient des données. Il sait que tout cette zone est "pourrie" et l'éjectera "manu-military". De mon coté, j'ai déjà fait des essais avec 2 disques entrelacés de 2To remlis à 97% (je suis toujours entre 97 et 99,5% sur mon nas perso), j'ai lancé plusieurs copies et j'ai coupé le courant ! na ! et bien au redémarrage, le nas ne dit rien, ça ne le gène pas, il fait comme si rien ne s'était passé ... il ne détecte pas d'erreur. Il a géré la situation.
Ce qu'il faut comprendre, c'est que si tu n'as pas de disques de log, ZFS crée des zones directement sur le pool et ces zones ne seront validées que sur l'état d'un bit (on peut pas faire moins que l'état binaire ! ... enfin si, mais bon si on parle du chat de Shrödinger et la mécanique quantique, là on va un "peu" se perdre).
Donc en gros, c'est un seul bit qui va valider tout le travail des écritures sur un pool ZFS. Tant que ce bit n'est pas changé, tout peut arriver, rien n'altérera le pool.
C'est pour cela que ZFS est indestructible.
C'est tout ce mécanisme qui demande de la RAM à ZFS, et c'est l'ARC qui permet cela.

Mais ZFS n'a pas forcément besoin de grosse quantité de RAM pur fonctionner, d'ailleurs après un démarrage, la RAM est vide et si tu accèdes au pool, tout marche.
C'est au fur et à mesure des lectures et écritures que le cache va s'éttofer, et si la RAM manque, le système tournera à la vitesse des disques comme après un démarrage, alors que si il a beaucoup de RAM, il tournera avec du cache en RAM.
On peut déplacer la ZIL dans un endroit dédié: le log (l'idéal en SSD), mais on peut aussi utiliser en disque dur, on peut avoir deux disques de log rapide (7200 ou 10000tr avec un bon cache-disque interne sur le disque) et avoir ensuite des disques lent (5400tr) pour le pool.
Cela doit se faire en connaissant le type de données qui sera parcouru dans le pool.
J'ai fais une fois un essai, j'ai mis un gros disque de cache et un disque de log, avec un pool de 2To uniquement en iscsi (mirroir de 4 disques), mes disques iscsi avaient un taux de transfert 6 fois plus faible que le disque de cache-ZFS, et bien à l'utilisation (lecture de fichier de plusieurs dizaine de Go), tout le nas fonctionnait à la vitesse du disque de cache, d'ailleurs après un accès aux données, il n'utilisait carrément plus les disques iscsi.
C'est pour cela que ZFS est génial, on peut se faire un nas "de guerre" avec "pas grand chose".

Maintenant, revenons en à nous, le nas possède des réglages d'origine qui indique à ZFS quelle taille de mémoire utiliser.
J'avais à une époque, une taille d'origine de 330To de configurée pour une RAM physique de 4Go !!! Il n'était donc pas surprenant que lorsque je sollicitais grandement ZFS, celui-ci avait des problèmes.
En réglant, la valeur à 3Go, mon nas n'avait plus de problème pour la RAM.
La rêgle de 1Go par To est une rêgle arbitraire mais n'est pas exacte. Si tu as 1Go, ZFS peut fonctionner. Il fonctionnera sans certaines couches de cache et lira donc beaucoup le disque et les performances seront "limitées".
Si au contraire, tu ajoutes de la RAM, ZFS l'utilisera et plus il y en a, plus les différentes couches seront utilisées et donneront un système performant.

Malheureusement, et c'est là que c'est important, c'est que les variables de ZFS ne sont pas positionnées comme il le faut.
Elles sont positionnée arbitrairement pour une utilisation courante (mais a grande échelle tout de même).
Pour moi, il faudrait que ZFS teste sa RAM au démarrage et qu'il positionne les valeurs de ZFS en conséquence. Cela éviterait beaucoup de déboires car ce pb de RAM est récurrent.

Dans ton cas, je pense que dès que tu accèdes au pool, l'ARC remplit toute la mémoire et ensuite provoque un comportement hasardeux du nas.
Peut-être qu'avec les version précédentes, il rebooterait.

Donc, soit tu rajoutes de la mémoire en espérant que cette taille permettra à l'ARC de gérer pleinement tes données ou tu rêgles ZFS pour "passer" l'obstacle en acceptant un niveau de performance "limité".