PoBot
NFS et Mini2440Cet 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/mountpointL’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.
Vos commentaires
# Le 9 avril 2011 à 06:29, par farhad
En réponse à : NFS et Mini2440
note très utile, fait gagner du temps aux autres...
Répondre à ce message
# Le 21 février 2011 à 14:13, par Aurel
En réponse à : NFS et Mini2440
Merci beaucoup pour les options.
Ca m’a éviter pas mal d’heure de recherche sur internet.
Répondre à ce message
# Le 30 décembre 2010 à 11:48, par David
En réponse à : NFS et Mini2440
Bravo Eric,
Une chouette tranche de vie d’expérimentation.
Je souhaite rebondir sur "(A propos des flash) : Ce point est juste une supposition, car cela n’a jamais montré de problème sur les micro-contrôleurs"
Je ne partage entièrement cet avis, car c’est dans cette intention que le constructeur indique un MTBF pour
la flash. En l’occurrence la 2440 est équipée d’une K9F1208 pour les programmes, même si le constructeur annonce 100 000 cycles programme/effacement de blocks[2] il faut le prendre en considération car elle est soudée (CMS) sur la carte et que dans le cas d’un développement cela arrive très très souvent.
Maintenant il faut pondérer cela :
– 100 000 cycles c’est pas mal
– le driver de flash gère cela en n’utilisant un cycle d’effacement que lorsque c’est nécessaire
– le driver ne vas pas utiliser bêtement un fichier temporaire en flash, il le fera ailleurs. En ram par exemple (si possible) .
– le driver va gérer la table de bads blocks
Cela apporte que plus d’intérêt à cet article et que le NFS est à considérer
de très prêt.
2e ref :
http://www.friendlyarm.net/dl.php?file=K9F1208.pdf
voir également p16 pour les bad bocks
# Le 30 décembre 2010 à 14:35, par Eric P.
En réponse à : NFS et Mini2440
Salut David,
Merci pour ton commentaire.
Je suis d’accord avec toi sur le fait qu’une flash a une durée de vie réduite par nature. Cependant, je suis presque certain que la carte sera retirée du service (pour cause d’autre panne ou par simple obsolescence ou lassitude personnelle) bien avant qu’on ait épuisé le quota de cycles par le seul fait de copier les binaires en développement.
Si on fait un calcul simple sur les hypothèses suivantes :
– 4 heures de travail non-stop sur la carte par session de travail
– une moyenne de 5 sessions de travail par semaine
– une copie du binaire toutes les 3 minutes pendant l’intégralité de la session
– 100 000 cycles maxi
on arrive à une durée de vie de la carte de presque 5 ans. Et cela suppose qu’on utilise systématiquement les mêmes blocs, ce qui n’est pas le cas dans la réalité.
Vue la fréquence avec laquelle je travaille sur cette carte, je pense donc que je serai passé à autre chose bien avant d’avoir tué la flash par réécriture.
De plus comme tu le soulignes, la couche de gestion de la flash (et également le file system utilisé) s’arrange pour d’une part répartir les écritures et d’autre part gérer les bad blocks qui apparaissent. Ces deux facteurs vont donc augmenter la durée de vie effective globale de la flash.
Je me souviens avoir eu exactement les mêmes angoisses au tout début de mes bricolages sur micro-contrôleur, mais après avoir fait le même genre de calcul, j’ai rangé ces angoisses dans la rubrique "ne pas se prendre la tête avec". Et je n’ai jamais grillé une flash de µP.
Ceci étant, tu as parfaitement raison de rappeler ces éléments, qui font partie des différences importantes entre PC et carte embarquée, et qu’il est bon de connaître, ne serait-ce que pour culture générale.
Répondre à ce message