Soit le makefile suivant :
all: test
toto:
test.c: toto
touch test.c
test.o: test.c
touch test.o
test: test.o
touch test
Ensuite, on fait une petite boucle en shell pour appeler une dizaine de fois la commande make.En principe, on doit obtenir 10 fois la séquence suivante :
touch test.c
touch test.o
touch test
Si ce test est fait à partir d'un répertoire monté en NFS, ça ne marche pas :touch test.c
touch test.o
touch test
touch test.c
touch test.c
touch test.c
touch test.c
touch test.c
touch test.c
touch test.c
touch test.c
touch test.c
Ceci semble lié à la machine qui exporte le filesystem car :- en local sur une machine Linux : OK
- montage NFS entre deux machines Linux : KO
- en local sur une machine Sun : OK
- montage NFS entre deux machines Sun : OK
- montage NFS d'un filesystem Linux vers Sun : KO
Je précise que notre admin (ce n'est pas moi qui exploite le serveur de fichier sous Linux) a tenté pas mal de combinaisons entre les options d'export et les options de montage : rien à faire.
De plus, les machines sont à la même date (ntpdate).
Notre serveur de fichiers est en RH 7.2.
Si quelqu'un a une piste...
Merci d'avance.
# NFS + Makefile : synchronisation de l'heure nécessaire.
Posté par tontonflingueur . Évalué à 0.
Il faut donc absolument que la date sur ton client et ton serveur
soient parfaitement synchronisés. Je te conseille d'utiliser NTP.
xntpd est normalement fourni sur tous les UNIX propriétaires, et aussi
sur la plupart des distributions Linux.
@+
[^] # Re: NFS + Makefile : synchronisation de l'heure nécessaire.
Posté par pini . Évalué à 1.
# Est-ce si grave finalement ?
Posté par tontonflingueur . Évalué à 2.
Ceci dit :
* l'utilisation de xntpd assure une synchronisation continue, ce qui n'est pas le cas de ntpdate, mais ceci dit j'utilise ntpd et j'ai le même problème ici.
* ensuite, vu les noms, tu veux tester ton makefile pour une des compilations. Il faut bien voir qu'il y a une différence entre touch et cc.
touch intervient sur la date et l'heure du fichier. C'est donc une opération extrêmement courte, alors qu'une compilation est beaucoup plus longue. Même avec xntpd, la synchronisation n'est pas parfaite vu que touch est très courte, tu tombes au-dessous de la marge d'erreur
de make.
En outre, j'ai le problème si je boucle sans temporisation. En faisant la boucle avec une temporisation de 1s, je n'ai plus d'erreur. Un développeur ne va pas s'amuser à compiler plusieurs fois par secondes pas vrai ?
@+
[^] # Re: Est-ce si grave finalement ?
Posté par pini . Évalué à 1.
C'est dans le cadre de l'utilisation d'un atelier logiciel conséquent et je peux t'assurer que le makefile généré ne fait pas que des touch !
J'ai bien entendu fait le test avec des sleep 1 avant le touch test.c. Ça marche. Mais je n'ai pas la main sur le makefile généré par l'atelier logiciel...
[^] # Options sync et no_wdelay sur exports sync et dirsync au mount
Posté par tontonflingueur . Évalué à 1.
* les options sync et no_wdelay au niveau de l'exports.
* sync et dirsync sur mount.
@+
[^] # Re: Options sync et no_wdelay sur exports sync et dirsync au mount
Posté par pini . Évalué à 1.
# Version de noyau...
Posté par pini . Évalué à 1.
- en local sur une machine Debian woody : KO
- en local sur une machine Debian sarge avec noyau 2.6 : OK
J'attends de pouvoir faire le test sur Sun avec un filesystem exporté par une Debian sarge + kernel 2.6.
Mais j'anticipe que la solution serait d'upgrader notre serveur de fichiers. Lourd, quoi...
[^] # Suite et fin
Posté par pini . Évalué à 2.
On va donc commencer à réfléchir à l'upgrade de notre serveur :o/
# TOTO ?
Posté par Obsidian . Évalué à 1.
[^] # Re: TOTO ?
Posté par pini . Évalué à 2.
La cible toto n'est là dans mon exemple que pour forcer le touch systématique de test.c. Et ça ça marche.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.