C'est un essai qui a été fait; le fichier est bien présent sur le server.
Et c'est logique car la 1ere étape est classique: C1 écrit sur S, ça , ça marche. C'est le modèle classique NFS client server.
C'est après que ça se gâte. Comment est-que C2 est notifié du changement? Pourquoi le serait-t-il systématiquement.
Ceci en plus est corroboré par le 2eme cas que je cite dans le post initial.
Quand enfin C2 a réussi à voir le fichier, il fait un traitement très rapide, et détruit ce même fichier. Ce rm se passe bien entre C2 et S. Mais, C1 cette fois ne voit pas le fichier disparaitre et tout part en vrac.
C'est la même situation que celle du début, mais inversée, et on a la même punition.
Non!
D'abord, c'est pas "Apparemment tu as deux machines"!
J'ai 3 machines, et c'est bien là la spècificité du problème.
J'ai 2 clients, et un server.
Et j'ai 1 seul script qui fait:
C1> touch /S1_SHARE/F1
C1> tempo paramètrable
C1> ssh C2 ls /S1_SHARE/F1 > /tmp/res
Et ensuite, soit je teste le $? du ssh , soit le contenu du /tmp/res par un grep, etc
Il y a un grand nombre de façons de le faire!
Et je compte le nombre de défauts, et je recommence en effaçant F1 par exemple depuis C1, mais il y a un grand nombre de cas où le pb apparait de manière incontestable.
Mais, y a pire!
Si je suis loggué sur C1
et j'ouvre une 2eme Konsole sur C2 (via ssh ou telnet peu importe)
depuis C1> je fais touch /S1SHARE/F1
_Bon, là il est créé, c'est sûr!
Et, depuis la console que je viens d'ouvrir sur C2
C2> ls /S1_SHARE/F1
1 fois sur 10 (ou plus ou moins, en général, quand ça commence à merder, c'est mort..)
et bien, là depuis C2 je ne vois pas /S1_SHARE/F1
Tous les caches sont déja à 0, ACTIMO aussi, au prix de perf's lamentables.
Il ne s'agit pas de trouver une autre solution, il s'agit de réparer ou du moins de comprendre ce qui cloche dans celle-là!
Je reproduit l'erreur par un script en bash. En fait l'écriture par C1 d'un fichier, c'est un touch!
Et une fois sur 10, le mécanisme échoue, dans mon script ou la vraie vie.
Donc, il est fermé. On ne peut pas mettre en cause les hypothéses.
J'ai tourné le pb dans tous les sens; le fichier est fermé et bien fermé!
Tous les caches sont à 000 et c'est nok!
La seule question, dans ce shéma C1 --> S --> C2 --> S --> C1
c'est: qu'est-ce qui n'a pas marché?
Oui, d'accord, mais c'est un autre débat (bien vaste...).
Concernant ce pb de tar sous Linux, on voit bien que le server NAS sous Windows n'est pas en cause!
Puisque depuis un Client NFS Sun Solaris 8 qui monte le même point de montage et avec la même commande (hyper simple: tar cvf ...) ca marche normalement.
C'est bien Linux ou/et la RedHat (3 ou/et 4) qui a un gros bug! Je ne sais pas comment je pourrais le faire remonter... Je n'espère pas une correction, faut pas réver, mais au moins le signaler.
Si je mets LD_LIBRARY_PATH dans le .kshrc, ca marche. Je ne sais pas s'il peut y avoir des effets de bord (pour cette variable et pour l'ensemble du process de login), mais ca constitue un bon contournement.
Merci encore.
PS
Bonjour
Quand je source le .profile, ca marche.
Par contre, meme si je remonte LD_LIBRARY_PATH dans le .profile, ca ne marche toujours pas (alors que toutes les autres variables d'environnement sont positionnées comme je le veux)
Je vais essayer dans le .kshrc
Merci pour votre réponse.
PS
Bonjour,
J'ai essayé, mais ca ne marche pas. En effet toutes les variables d'environnement sont positionnées SAUF LD_LIBRARY_PATH.
Je vous remercie néanmoins pour votre réponse très détaillée.
PS
[^] # Re: Pas une parole d'expert, mais néanmoins une parole!
Posté par pierre31 . En réponse au message problème de dialogue entre 2 clients d'un même server NFS. Évalué à 0.
C'est un essai qui a été fait; le fichier est bien présent sur le server.
Et c'est logique car la 1ere étape est classique: C1 écrit sur S, ça , ça marche. C'est le modèle classique NFS client server.
C'est après que ça se gâte. Comment est-que C2 est notifié du changement? Pourquoi le serait-t-il systématiquement.
Ceci en plus est corroboré par le 2eme cas que je cite dans le post initial.
Quand enfin C2 a réussi à voir le fichier, il fait un traitement très rapide, et détruit ce même fichier. Ce rm se passe bien entre C2 et S. Mais, C1 cette fois ne voit pas le fichier disparaitre et tout part en vrac.
C'est la même situation que celle du début, mais inversée, et on a la même punition.
[^] # Re: Pas une parole d'expert, mais néanmoins une parole!
Posté par pierre31 . En réponse au message problème de dialogue entre 2 clients d'un même server NFS. Évalué à 0.
Non!
D'abord, c'est pas "Apparemment tu as deux machines"!
J'ai 3 machines, et c'est bien là la spècificité du problème.
J'ai 2 clients, et un server.
Et j'ai 1 seul script qui fait:
C1> touch /S1_SHARE/F1
C1> tempo paramètrable
C1> ssh C2 ls /S1_SHARE/F1 > /tmp/res
Et ensuite, soit je teste le $? du ssh , soit le contenu du /tmp/res par un grep, etc
Il y a un grand nombre de façons de le faire!
Et je compte le nombre de défauts, et je recommence en effaçant F1 par exemple depuis C1, mais il y a un grand nombre de cas où le pb apparait de manière incontestable.
Mais, y a pire!
Si je suis loggué sur C1
et j'ouvre une 2eme Konsole sur C2 (via ssh ou telnet peu importe)
depuis C1> je fais touch /S1SHARE/F1
_Bon, là il est créé, c'est sûr!
Et, depuis la console que je viens d'ouvrir sur C2
C2> ls /S1_SHARE/F1
1 fois sur 10 (ou plus ou moins, en général, quand ça commence à merder, c'est mort..)
et bien, là depuis C2 je ne vois pas /S1_SHARE/F1
[^] # Re: Use of NFS considered harmful
Posté par pierre31 . En réponse au message problème de dialogue entre 2 clients d'un même server NFS. Évalué à 0.
Tous les caches sont déja à 0, ACTIMO aussi, au prix de perf's lamentables.
Il ne s'agit pas de trouver une autre solution, il s'agit de réparer ou du moins de comprendre ce qui cloche dans celle-là!
[^] # Re: Pas une parole d'expert, mais néanmoins une parole!
Posté par pierre31 . En réponse au message problème de dialogue entre 2 clients d'un même server NFS. Évalué à 0.
Je reproduit l'erreur par un script en bash.
En fait l'écriture par C1 d'un fichier, c'est un touch!
Et une fois sur 10, le mécanisme échoue, dans mon script ou la vraie vie.
Donc, il est fermé. On ne peut pas mettre en cause les hypothéses.
J'ai tourné le pb dans tous les sens; le fichier est fermé et bien fermé!
Tous les caches sont à 000 et c'est nok!
La seule question, dans ce shéma C1 --> S --> C2 --> S --> C1
c'est: qu'est-ce qui n'a pas marché?
[^] # Re: remplacer le server (SFU-NFS) Windows par Samba/Linux/NFS
Posté par pierre31 . En réponse au message tar symbolic link mal restitués sur FS NFS NTFS. Évalué à 1.
Concernant ce pb de tar sous Linux, on voit bien que le server NAS sous Windows n'est pas en cause!
Puisque depuis un Client NFS Sun Solaris 8 qui monte le même point de montage et avec la même commande (hyper simple: tar cvf ...) ca marche normalement.
C'est bien Linux ou/et la RedHat (3 ou/et 4) qui a un gros bug! Je ne sais pas comment je pourrais le faire remonter... Je n'espère pas une correction, faut pas réver, mais au moins le signaler.
Merci quand même.
Pierre S
[^] # Re: Nok: seule LD_LIBRARY_PATH est concernée.
Posté par pierre31 . En réponse au message LD_LIBRARY_PATH Not Set sous KDE enviro (RH4). Évalué à 1.
Merci encore.
PS
[^] # Re: Nok: seule LD_LIBRARY_PATH est concernée.
Posté par pierre31 . En réponse au message LD_LIBRARY_PATH Not Set sous KDE enviro (RH4). Évalué à 1.
Quand je source le .profile, ca marche.
Par contre, meme si je remonte LD_LIBRARY_PATH dans le .profile, ca ne marche toujours pas (alors que toutes les autres variables d'environnement sont positionnées comme je le veux)
Je vais essayer dans le .kshrc
Merci pour votre réponse.
PS
[^] # Nok: seule LD_LIBRARY_PATH est concernée.
Posté par pierre31 . En réponse au message LD_LIBRARY_PATH Not Set sous KDE enviro (RH4). Évalué à 1.
J'ai essayé, mais ca ne marche pas. En effet toutes les variables d'environnement sont positionnées SAUF LD_LIBRARY_PATH.
Je vous remercie néanmoins pour votre réponse très détaillée.
PS