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.
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 :
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).
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é.
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 ...
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.