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

4. Installer un client NFS

Tout d'abord il faudra compiler un noyau avec le système de fichiers NFS, soit compilé dans le noyau, soit disponible sous forme de module. Si vous n'avez encore jamais compilé un noyau vous aurez peut être besoin de consulter le HOWTO du noyau. Si vous utilisez une distribution très cool (comme Chapeau Rouge) et que vous n'avez jamais trifouillé le noyau (pas toucher toucher) il y a des chances que NFS soit automagiquement disponible.

Vous pouvez maintenant, à l'invite (prompt) du root, entrer la commande mount appropriée et le système de fichiers apparaîtra. Continuons avec l'exemple de la section précédente, nous voulons monter /mn/eris/local depuis eris. La commande est :

mount -o rsize=1024, wsize=1024 eris:/mn/eris/local /mnt

Nous reviendrons plus tard sur les options rsize et wsize. Le système de fichiers est maintenant disponible sous /mnt et vous pouvez faire un cd sur lui, puis un ls et regarder les fichiers individuellement. Vous remarquerez que ce n'est pas aussi rapide qu'avec un système de fichiers local, mais beaucoup plus pratique que ftp. Si, au lieu de monter le système de fichiers, mount renvoie un message d'erreur comme mount: eris:/mn/eris/local failed, reason given by server: Permission denied alors le fichier exports est incorrect, ou vous avez oublié de lancer exportfs après avoir modifié le fichier exports. S'il dit mount: clntudp_ipdate: RPC: Program not registered cela signifie que nfsd ou mountd ne tourne pas sur le serveur, ou que vous avez le problème avec les fichiers hosts.{allow,deny} mentionné plus haut.

Pour vous débarrasser du système de fichiers, vous pouvez faire :

umount /mnt

Pour que le système monte automatiquement un système de fichiers NFS au démarrage, éditez /etc/fstab de la façon habituelle. Par exemple avec une ligne comme celle-ci :

# device       mountpoint    fs-type    options           dumps  sfckorder
...
eris:/mn/eris/local   /mnt   nfs     rsize=1024,wsize=1024   0   0
...

C'est presque tout ce qu'il y a à savoir. Vous pouvez jeter un coup d'oeil à la page de manuel nfs. Continuons plize.

4.1 Options de montage

Il y a trois comportements principaux des clients NFS en cas de chute du serveur qui sont spécifiés par les options de montage :

soft

Le client NFS renverra une erreur au processus concerné si après quelques essais le serveur NFS persiste à ne pas répondre. Si vous voulez utiliser cette option, vous devez vérifier que votre logiciel la gère correctement. Je ne recommande pas ce réglage, c'est un bon moyen de perdre des données et corrompre des fichiers. En particulier, n'utilisez pas ça pour les disques où sont stockés vos mails (si vous tenez à vos mails).

hard

Le client NFS réessaiera infiniment jusqu'à ce qu'il soit tué. Les opérations reprendront normalement si le serveur NFS se rétablit ou redémarre. Le client ne pourra pas être interrompu ou tué.

hard,intr

Comme hard, mais Ctrl-C tuera le processus bloqué. Dans quelques cas, notament un disque /usr/spool/mail monté par NFS cela ne changera rien car le shell ignore le Ctrl-C quand il teste si vous avez du mail. Je recommande cette option pour tous les systèmes de fichiers NFS, y compris le spool du mail.

Reprenons l'exemple précédent, votre entrée fstab est maintenant :

# device       mountpoint   fs-type    options            dumps  sfckorder
...
eris:/mn/eris/local   /mnt  nfs   rsize=1024,wsize=1024,hard,intr 0   0
...

4.2 Optimisation de NFS

Normalement, si les options rsize et wsize ne sont pas précisées, NFS écrira et lira par blocs de 4096 ou 8192 octets. Mais certaines combinaisons de noyau Linux et cartes réseau ne peuvent pas fonctionner avec ces valeurs, de plus, même si cela marche, cela peut ne pas être optimal du tout. Il nous faudra donc expérimenter et trouver les valeurs de rsize et wsize qui fonctionnent et donnent les transferts les plus rapides. Vous pouvez tester la vitesse obtenue avec différentes valeurs des options avec des commandes simples. La commande mount ci-dessus ayant été exécutée, si vous avez l'accès en écriture sur le disque vous pouvez tester les performances en écriture séquentielle :

time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096

Ceci crée un fichier de 64 Mo ne contenant que des 0. Faites le quelques (5-10?) fois et prenez la moyenne des temps. C'est le temps `elapsed' ou `wall clock' qui est le plus intéressant. Ensuite vous pouvez tester les performances en lecture en relisant le fichier :

time dd if=/mnt/testfile of=/dev/null bs=16k

faites le quelques fois et prenez la moyenne. Puis démontez (umount) et remontez (mount) avec des valeurs plus grandes pour rsize et wsize. Il vaut mieux prendre des multiples de 1024, et probablement pas plus grand que 16384 octets, car les gros blocs ralentissent les accès aléatoires. Immédiatement après avoir remounté avec une taille supèrieure, placez vous (cd) dans le système de fichiers et faites des trucs comme ls, explorez un peu pour vérifier que tout est bien normal. Si la valeur de rsize/wsize est trop grande, les symptômes sont vraiment bizarres et pas évidents. Un symptôme typique est une liste de fichiers donnée par ls incomplète sans aucun message d'erreur. Ou la lecture de fichier qui échoue mystérieusement et sans message d'erreur. Après vous être assurés que les wsize/rsize choisis fonctionnent, vous pouvez faire les tests de rapidité. Différentes plateformes de serveur auront peut-être des tailles optimales différentes. SunOS et Solaris sont réputés pour être beaucoup plus rapides avec une taille de 4096 octets.

Les noyaux Linux récents (depuis 1.3) font parfois des lectures anticipées (read ahead) pour des rsizes supérieurs ou égaux à la taille de page de la machine. Sur les processeurs Untel la taille de la page est de 4096 octets. La lecture anticipée augmentera sensiblement les performances en lecture. Sur une machine Untel on devrait donc choisir un rsize de 4096 si c'est possible.

Un truc pour augmenter les performances d'écriture de NFS est d'invalider les écritures synchrones sur le serveur. Les spécifications de NFS disent que les requêtes d'écriture de NFS ne doivent pas être considérées comme terminées avant que les données ne soient sur un médium non versatile (normalement le disque). Ceci réduit les performances à l'écriture, les écritures asynchrones sont plus rapides. Le nfsd Linux ne fait pas d'écritures synchrones car l'implémentation du système de fichiers ne s'y prête pas, mais sur les serveurs non Linux vous pouvez augmenter les performances de cette façon dans votre fichier exports :

/dir    -async, access=linuxbox

ou quelque chose du genre. Référez vous à la page de manuel exports de la machine concernée. Notez que ceci augmente les risques de perte de données.

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