nfs+raidsoft+smp+tar=reboot
Par Olivier le mardi 15 juin 2004, 00:00 - Journal de geek - Lien permanent
Texte initialement publié sur LinuxFR
Bonjour,
avant d'aller prendre un peu de repos, une petite synthèse s'impose
Bonjour,
avant d'aller prendre un peu de repos, une petite synthèse s'impose
Sur mon serveur@home, j'ai constaté plusieurs fois depuis 1 an des reboots qui avaient l'air totalement aléatoires, la fréquence très faible (< 1 par mois) ne m'a pas aidé à trouver l'origine du problème. Mes tentatives de pseudo "stress-tests" ne donnaient rien...
Aujourd'hui par hasard j'ai compris, et j'ai une recette reproductible à 100%
Sur une station 'puissante' (ici un PIII@866)
tar -cf /mnt/nfs/hang.tar /home (avec un peu plus de 2Go à copier)
Il ne finit jamais le tar, le serveur reboot systèmatiquement avant.
La meme chose sur un PII@233 fonctionne.
Les tests ou modifs effectués jusqu'ici:
- activé le NFS sur TCP coté serveur et client: reboot idem
- gros transfert de disque à disque, de /dev/zero à disque, de disque à /dev/null pour générer un max d'IO, ras, machine stable
- gros transfert réseau (du serveur vers les stations et des stations vers le serveur) avec des ping -f et/ou tcpspray, ras stable
Les chose que je penses faire:
- tester avec un 2.6
- tester avec un autre protocole que nfs (ftp?)
Une recherche m'a sorti un cas similaire causé par les drivers binaires nvidia, mais mon serveur est un headless, je n'ai pas de nvidia dedans,et d'ailleurs le noyau est très allégé de ce coté là..
La config du serveur:
Debian stable
noyau perso 2.4.26, patché cryptoloop (mais le problème existe depuis au moins le 2.4.22)
Bi-PII@400Mhz
Raid1+Raid5 soft
Chipset:
00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
Controleurs IDE:
00:04.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01)02:01.0
Unknown mass storage controller: Promise Technology, Inc. 20268 (rev 02)
Vala, je continuerais à fouiller, mais si vous avez liens/idées/suggestions/solutions, n'hésitez pas.
Commentaires
Tu as un moyen (bios, lm_sensors, ...) de vérifier la température du cpu/chipset au cours de l'opération ? Mon pc reboote tout seul quand il a trop chaud.
C'est drole parce que j'ai exactement le meme probleme, sauf que je ne sais pas encore d'ou ca vient.
Mais ce n'est pas la chaleur :]
ca se passe par tranche, parfois jen ai 10 a la suite avec 5 mn d'intervalles, parfois j'en ai pas pendant 2 semaines.
c'est bizarre, peut etre un probleme materiel, mais jvais voir du coté de mes disques maintenant que j'ai lu ton truc.
(question: qu'utilises-tu comme fs ? ici c'est du xfs, jme demandais si ca pouvait avoir un rapport .. ..)
J'avais eu quelques soucis pour lm_sensors (pas trouvé et pas forcé), mais j'ai mis un thermomètre externe avec une sonde sur le dissipateur, T° tjrs inférieure à 43-44°.
De toute façon je fais tourner un seti@home par proco dessus, alors Je dirais aucun lien entre le reboot et la température.
Le fs utilisé est ext3.
Cas similaire sur un "serveur" (vaste qualificatif pour un bi-celeron 466) qui accumule les soucis de ce genre.
Par ordre d'apparition à l'écran, j'ai eu :
- barette de RAM défectueuse
- gestion catastrophique des interruptions sur certains ports PCI (d'où forts traffics réseaux ---> blocage)
- partition swap vérolée (mkswap -c -v1 et ça repart)
Ce qui est curieux, c'est que dans les trois cas, la machine répondait au ping mais était en time-out sur tous les autres services réseaux et les procs devaient (pas vu car pas d'écran) tourner à fond car la température était très élevée. Probablement un kernel panic mais difficille de voir sans clavier ni écran et plus de ssh
J'attends avec "impatience" le prochain souci... (en espérant secretement que c'était le dernier)
PS: il me semble que sur les chipsets 440ZX (si c'est ton cas) il y avait des problèmes de gestion des interruptions.
PS: j'ai eu souvent des soucis avec le serveur nfs du noyau (nfs-kernel-server pour Debian). Depuis que je suis passé en nfs-user (nfs-user-server), ça va beaucoup mieux.
PS: Unknown mass storage controller: Promise Technology, Inc. 20268 (rev 02) Tu peut passer ton lspci en testing (mais nécessite une mise à jour de la libc6...) pour le reconnaitre.
Après pas mal de tests, j'ai fini par comprendre en parti et à résoudre mon souci:
Ca ne marchait pas mieux en fait sur les PC plus lents, même problème constaté sur le PII. En fait le PII avait _un tout petit peu_ moins de 2 Go de données.
Donc le problème tournait autour du support LFS (fichiers > 2Go) j'avais activé l'option nfsv3 dans le noyau mais je n'avais pas mis l'option qui va bien dans les fstab des clients.
En NFSv3, plus de souci, je peux copier tout ce que je veux, plus de plantage.
Si je comprends bien pourquoi les fichiers de + de 2 go ne passaient pas, je ne comprends pas pourquoi lorsque un client essaye, ça fait rebooter le serveur
c'est pas normal ça (bel euphémisme).
A la prochaine