NFS et Mini2440

Cet article n’a aucune prétention en tant que tutorial, documentation,... Il ne fait que retracer une mésaventure récente rencontrée avec la mise en place de NFS et comment j’ai pu m’en sortir.

Encore une fois, je ne prétends pas que la méthode utilisée présente une quelconque valeur, mais comme elle a marché dans mon cas, j’ai pensé que cela pourrait aider d’autres personnes.

 Le contexte

Dans le cadre de mes pérégrinations dans le monde de la Mini2400 et de Qt, j’en ai vite eu assez de devoir transférer les binaires sur la carte via ftp à chaque re-compilation pour pouvoir les tester.

De plus, je ne suis pas certain que réécrire aussi souvent sur la flash soit très bon pour sa durée de vie. Ce point est juste une supposition, car cela n’a jamais montré de problème sur les micro-contrôleurs. Ceci étant, le prix de la carte étant quand même supérieur à celui d’un ATmega, il vaut mieux rester prudent.

L’idée est donc de monter via NFS le répertoire de la machine de développement sur laquelle les binaires sont générés, et de tester cela sur la Mini2440 sans avoir l’application en local. Rien que de très banal à priori.

 Mise en place côté serveur

Ma machine de travail est sous Ubuntu 10.04. J’y ai installé nfs-server-kernel par les moyens habituels (synaptic, apt-get,... selon vos préférences)

Pour ce qui est de la déclaration des exports, il suffit d’ajouter la ligne correspondante dans /etc/exports. J’ai utilisé les options suivantes : ro,sync,no_subtree_check

Ce qui est à retenir là-dedans est l’export en read-only, car il n’y a aucune raison d’écrire quoi que ce soit depuis la carte. De plus cela permet d’utiliser sans risque une des méthodes de contournement de problème décrites plus loin.

 Côté carte : problème 1

Le montage de répertoire NFS se fait en principe tout simplement par la commande : mount <ip-server>:/path/to/exported/directory /path/to/local/mountpoint

L’exécution de la commande sous cette forme se solde par une absence totale de réponse. On arrive à reprendre la main au bout de plusieurs minutes à grands coups de Ctrl-C et autres. J’avoue ne pas avoir eu la patience d’attendre suffisamment longtemps pour voir s’il y avait un quelconque timeout qui remet les choses en ordre proprement.

Pour éviter cela, il a fallu ajouter l’option nolock à la commande de la manière suivante : mount -o nolock <ip-server>:....

D’après la doc, cette option supprime les échanges d’informations de lock entre client et serveur. Si cela peut s’avérer gênant dans le cas d’accès multiples et/ou en lecture/écriture de part et d’autre, ce n’est pas le cas ici puisque le répertoire est exporté en lecture seule (cf plus haut). De plus ça supprime des échanges entre les partenaires, ce qui ne peut qu’aller dans le bon sens concernant les performances.

 Côté carte : problème 2

Tout semblait ok jusqu’au moment où, après avoir testé en copiant des petits fichiers sans problème, j’ai cherché à copier un binaire d’application. La commande de copie ne rend pas la main, et après l’avoir killée avec Ctrl-C on constate que le fichier copié fait systématiquement 16384 octets très exactement (soit 0x4000 en hexa). Cela correspond à la taille de buffer par défaut au niveau NFS je crois.

Après avoir testé un tas d’options diverses au niveau de l’export, et passé quelques heures sur Google, j’ai fini par essayé de forcer le protocole à TCP (au lieu de UDP par défaut). La commande de montage devient alors : mount -o nolock,proto=tcp <ip-server>:....

Plus aucun problème à partir de ce moment-là.

Je n’ai rien trouvé de particulier sur Google concernant cette histoire d’UDP/TCP. Si ça se trouve c’est juste mon système qui a un pet de travers. Mais au cas où le vôtre aurait le même pet de travers, peut-être cela pourra-t-il vous dépanner, en attendant mieux, c’est à dire de trouver comment remettre les choses en ordre (soyez sympa et donnez-moi la soluce si vous la trouvez ;)).

A noter :

Dans le cadre de la recherche de l’anomalie, j’ai installé le serveur NFS sur une autre machine Ubuntu 10.04, et aucun problème de ce côté-là. Les transferts fonctionnent aussi bien avec et sans l’option proto.

A noter qu’au niveau du log système des serveurs, le système problématique comporte un message d’anomalie dans le syslog : svc: failed to register lockdv1 RPC service (errno 97).

D’après les recherches effectuées, cela pourrait avoir un rapport avec IPv6, mais je n’ai pas approfondi la question, car IPv6 semble être configuré et activé de la même manière sur les deux machines utilisées.

 Conclusion

Encore une fois, prenez ce qui précède que comme une trace de ce qui semble être la résolution de problèmes sur lesquels je suis tombé. Et rien de plus.