Page suivante Page précédente Table des matières

5. NFS sur les lignes à faible débit

Les lignes lentes (à faible débit) comprennent les modems, RNIS et aussi sans doute les autres connexions longue distance.

Cette section est basée sur la connaissance des protocoles utilisés mais pas sur des expérimentations. Faites moi savoir si vous essayez ceci ;-)

La première chose à retenir est que NFS est un protocole lent. Il a un grand overhead (sur-coût en bande passante). Utiliser NFS, c'est presque comme utiliser kermit pour transférer des fichiers. Il est lent. Presque tout est plus rapide que NFS. FTP est plus rapide. HTTP est plus rapide. rcp est plus rapide. ssh est plus rapide.

Vous voulez toujours l'essayer ? Ok.

Par défaut NFS est paramétré pour des lignes rapides et à faible latence. Si vous utilisez les paramètres par défaut sur des lignes à grande latence cela peut provoquer des erreurs, des annulations, des rétrécissements de fichiers, et des comportements bizarres.

La première chose à faire est de ne pas utiliser l'option de montage soft. Les temporisations retourneront des erreurs au logiciel, qui, dans l'immense majorité des cas, ne saura pas quoi en faire. C'est une bonne façon d'avoir des problèmes bizarres. Utilisez plutôt l'option de montage hard. Quand hard est actif les temporisations déclenchent des essais infinis au lieu d'annuler ce que le logiciel était en train de faire (quoi que ce soit). C'est ce que vous voulez. Vraiment.

La deuxième chose à faire est d'ajuster les options de montage timeo et retrans. Elles sont décrites dans la page de manuel nfs(5), en voici un extrait (version française) :


       timeo=n        La valeur,  en  dixiemes  de  secondes,  du
                      delai   avant  de  declencher  la  premiere
                      retransmission d'une RPC.   La  valeur  par
                      defaut  est 7/10 de seconde. Apres une pre­
                      miere expiration, le delai  est  double  et
                      l'on recommence les retransmissions jusqu'a
                      ce que le delai atteigne la valeur maximale
                      de 60 secondes, ou que le nombre maximal de
                      retransmission soit depasse.  Il se produit
                      alors  une  erreur  d'expiration majeure de
                      delai.  Si le systeme est monte  "en  dur",
                      les  retransmissions  reprendront a nouveau
                      indefiniment.

                      On peut ameliorer les performances en  aug­
                      mentant  le delai sur un  reseau charge, si
                      le serveur est un  peu  lent,  ou  si  l'on
                      traverse plusieurs routeurs ou passerelles.

       retrans=n      Le  nombre  d'expirations  mineures  et  de
                      retransmissions  qui  doivent  se  produire
                      avant de declencher une expiration majeure.
                      La  valeur  par  defaut  est  3 expirations
                      mineures.  Quand  une  erreur  d'expiration
                      majeure  se  produit,  soit l'operation est
                      abandonnee, soit  un  message  "server  not
                      responding" est affiche sur la console.

En d'autres mots : si une réponse n'est pas reçue avant la temporisation de 0,7 seconde (700 ms), le client NFS répétera la requête et doublera la temporisation à 1,4 seconde. Si la réponse n'arrive pas dans les 1,4 seconde, la requête est répétée à nouveau et la temporisation est doublée à 2,8 secondes.

La vitesse de la ligne peut être mesurée avec un ping ayant vos valeurs de rsize/wsize comme taille de paquet.


$ ping -s 8192 lugulbanda
PING lugulbanda.uio.no (129.240.222.99): 8192 data bytes
8200 bytes from 129.240.222.99: icmp_seq=0 ttl=64 time=15.2 ms
8200 bytes from 129.240.222.99: icmp_seq=1 ttl=64 time=15.9 ms
8200 bytes from 129.240.222.99: icmp_seq=2 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=3 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=4 ttl=64 time=15.0 ms

--- lugulbanda.uio.no ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 14.9/15.1/15.9 ms

Le temps indiqué est celui que le paquet du ping a pris pour aller et revenir de lugulbanda. 15 ms, c'est assez rapide. Sur une ligne à 28 800 bps vous pouvez vous attendre à une valeur de l'ordre de 4000-5000 ms, et si la ligne est chargée ce temps sera encore plus élevé, facilement le double. En général, la latence augmente avec la taille des paquets et la charge de la ligne. Si vous comptez utiliser FTP et NFS en même temps il faudra mesurer les temps du ping pendant un transfert FTP et augmenter timeo en accord avec la latence de votre ligne.


Page suivante Page précédente Table des matières