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.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:37