NFS(5) File Formats Manual NFS(5) NOM nfs - Format de fstab et options pour les systemes de fichiers nfs SYNOPSIS /etc/fstab DESCRIPTION NFS est un protocole aux normes de l'Internet cree par Sun Microsystems en 1984. NFS a ete developpe pour permettre le partage de fichiers entre des systemes connectes a un reseau local. Selon la configuration du noyau, le client Linux de NFS peut gerer les versions 3, 4.0, 4.1 ou 4.2. La commande mount(8) lie un systeme de fichiers a un point de montage donne dans la hierarchie d'espaces de noms du systeme. Le fichier /etc/fstab decrit la facon dont mount(8) doit recreer la hierarchie d'espaces de noms du systeme de fichiers a partir de systemes de fichiers independants (dont ceux exportes par des serveurs NFS). Chacune des lignes du fichier /etc/fstab decrit un seul systeme de fichiers, son point de montage et un ensemble d'options de montage par defaut pour ce point de montage. Dans le cas des montages de systemes de fichiers NFS, une ligne dans le fichier /etc/fstab indique le nom du serveur, le chemin du repertoire exporte a monter, le repertoire local qui sera le point de montage, le type de systeme de fichiers a monter et la liste des options de montage qui indiquent la facon dont le systeme de fichiers sera monte et quel sera le comportement du client NFS lorsqu'il accedera aux fichiers du point de montage. Les cinquieme et sixieme champs de chaque ligne ne sont pas utilises par NFS et par consequent contiennent par convention le chiffre zero. Par exemple : serv:chemin /pt_montage type_sdf option,option,... 0 0 Le nom du serveur et le chemin de partage sont separes par un deux-points, tandis que les options de montage sont separees par des virgules. Les champs restants sont separes par des espaces ou des tabulations. Le nom d'hote du serveur peut etre un nom d'hote non qualifie, un nom de domaine pleinement qualifie (<< fully qualified domain name >>), une adresse IPv4 sous forme de quadruplet avec points ou une adresse IPv6 entouree par des crochets. Les adresses IPv6 de liens locaux ou de sites locaux doivent etre accompagnees d'un identifiant d'interface. Consulter ipv6(7) pour des details quant a l'ecriture des adresses IPv6 brutes. Le champ type_sdf contient << nfs >>. La valeur << nfs4 >> est obsolete. OPTIONS DE MONTAGE Consultez mount(8) pour la description des options de montage generiques disponibles pour tous les systemes de fichiers. Si vous n'avez pas besoin d'indiquer d'options de montage particulieres, utilisez l'option generique defaults dans /etc/fstab. Options prises en charge par toutes les versions Les options suivantes peuvent etre utilisees avec n'importe quelle version de NFS. nfsvers=n Le numero de version du protocole NFS utilise pour contacter le service NFS du serveur. Si le serveur ne gere pas la version demandee, la requete de montage echoue. Si cette option n'est pas definie, le client essaie d'abord la version 4.2, puis essaie une version inferieure jusqu'a trouver une version prise en charge par le serveur. vers=n Cette option est une solution de remplacement de l'option nfsvers. Elle est incluse pour des raisons de compatibilite avec d'autres systemes d'exploitation. soft/softerr/hard Definir le comportement de recuperation du client NFS lorsqu'une requete NFS ne repond pas (delai depasse). Si aucune option n'est indiquee (ou si c'est l'option hard qui est indiquee), les requetes NFS sont retentees indefiniment. Si l'option soft ou l'option softerr est indiquee, le client NFS echouera apres l'envoi de retrans retransmissions, entrainant le renvoi par le client NFS de soit EIO (pour l'option soft) ou ETIMEDOUT (pour l'option softerr) a l'application appelante. NB : Un delai expire << soft >> peut provoquer dans certains cas des erreurs de donnees non signalees. C'est pourquoi l'option soft ou l'option softerr ne doivent etre utilisees que si la reactivite du client est plus importante que l'integrite des donnees. L'utilisation de NFS avec TCP ou l'augmentation de la valeur de l'option retrans peut diminuer les risques lies a l'utilisation de l'option soft ou softerr. softreval/nosoftreval Dans le cas ou le serveur NFS est hors service, il peut etre utile de permettre au client NFS de servir des chemins et des attributs a partir du cache apres retrans essais pour revalider ce que ce cache a invalide. Cela peut etre utile, par exemple, lors d'un essai de demontage d'un arbre de systeme de fichiers d'un serveur hors service de maniere permanente. Il est possible de combiner softreval avec l'option de montage soft, auquel cas les operations qui ne peuvent etre servies a partir du cache depasseront le delai imparti et renverront une erreur apres retrans essais. La combinaison avec l'option de montage par defaut hard implique que ces operations non mises en cache continueront d'essayer jusqu'a ce qu'une reponse soit recue du serveur. Remarque : l'option de montage par defaut est nosoftreval qui ne permet pas un repli vers le cache lorsque la revalidation echoue, et qui suit plutot le comportement dicte par les options de montage hard ou soft. intr/nointr Cette option est fournie pour la retrocompatibilite. Elle est ignoree apres le noyau 2.6.25. timeo=n Le temps en dixiemes de seconde pendant lequel le client NFS attend une reponse avant de reessayer une requete NFS. Pour NFS sur TCP, la valeur timeo est de 600 par defaut (60 secondes). Le client NFS effectue une progression lineaire : apres chaque retransmission la temporisation est augmentee de timeo jusqu'au maximum de 600 secondes. Cependant, dans le cas de NFS sur UDP, le client utilise un algorithme adaptatif pour estimer la valeur appropriee de depassement de temps pour les types de requetes frequemment utilisees (les requetes READ et WRITE par exemple), mais utilise le reglage timeo pour les requetes moins courantes (comme FSINFO). Si l'option timeo n'est pas definie, les types de requetes moins courantes sont reemises apres 1,1 seconde. Apres chaque retransmission, le client NFS double la valeur de depassement de temps pour cette requete, jusqu'a atteindre un maximum de 60 secondes. retrans=n Nombre de tentatives de reemission de la requete avant que le client NFS n'enclenche une action de recuperation. Si l'option retrans n'est pas definie, le client NFS essaye chaque requete UDP trois fois et chaque requete TCP deux fois. Le client NFS genere un message << le serveur ne repond pas >> apres retrans tentatives, puis enclenche la recuperation (qui depend de l'activation de l'option hard de mount). rsize=n Nombre maximal d'octets pour chaque requete reseau en LECTURE que peut recevoir le client NFS lorsqu'il lit les donnees d'un fichier sur le serveur NFS. La taille reelle de la charge utile de donnees pour chaque requete NFS en LECTURE est plus petite ou egale au reglage rsize. La plus grande charge utile geree par le client NFS Linux est de 1 048 576 octets (un megaoctet). La valeur de rsize est un entier positif multiple de 1024. Les valeurs de rsize inferieures a 1024 sont remplacees par 4096, et celles superieures a 1 048 576 sont remplacees par 1 048 576. Si la valeur indiquee est bien dans la plage geree, mais qu'elle n'est pas un multiple de 1024, elle sera arrondie au multiple de 1024 inferieur le plus proche. Si la valeur de rsize n'est pas definie, ou si la valeur de rsize depasse le maximum qu'a la fois le client et le serveur peuvent gerer, le client et le serveur negocient la plus grande valeur de rsize qu'ils peuvent gerer ensemble. L'option rsize de mount telle qu'elle a ete definie sur la ligne de commande lors du mount(8) apparait dans le fichier /etc/mtab. Cependant, la valeur reelle de rsize negociee entre le client et le serveur est indiquee dans le fichier /proc/mounts. wsize=n Nombre maximal d'octets par requete d'ECRITURE reseau que le client NFS peut envoyer quand il ecrit des donnees dans un fichier sur un serveur NFS. La taille reelle de la charge utile de donnees pour chaque requete NFS en ECRITURE est plus petite ou egale au reglage wsize. La plus grande charge utile geree par le client NFS Linux est de 1 048 576 octets (un megaoctet). Comme pour rsize, la valeur de wsize est un entier positif multiple de 1024. Les valeurs de wsize inferieures a 1024 sont remplacees par 4096, et celles superieures a 1 048 576 par 1 048 576. Si la valeur definie est bien dans l'etendue valable mais qu'elle n'est pas multiple de 1024, elle est arrondie au multiple de 1024 inferieur le plus proche. Si la valeur de wsize n'est pas definie, ou si la valeur wsize indiquee est superieure au maximum que soit le client, soit le serveur peuvent gerer, le client et le serveur negocient la plus grande valeur de wsize qu'ils peuvent tous les deux gerer. L'option wsize de mount telle qu'elle a ete indiquee sur la ligne de commande de mount(8) apparait dans le fichier /etc/mtab. Cependant, la valeur reelle de wsize negociee par le client et le serveur est indiquee dans le fichier /proc/mounts. ac/noac Definir si le client peut mettre en cache les attributs des fichiers. Si aucune option n'est indiquee (ou si c'est ac qui est indique), le client met en cache les attributs des fichiers. Afin d'ameliorer les performances, les clients NFS mettent en cache les attributs des fichiers. A intervalles de quelques secondes, un client NFS verifie la version du serveur de chaque attribut de fichier pour rechercher des mises a jour. Les modifications qui interviennent pendant ces petits intervalles restent inapercues tant que le client n'a pas consulte de nouveau le serveur. L'option noac empeche la mise en cache des attributs de fichiers par le client, ce qui permet aux applications de detecter plus rapidement les modifications des fichiers sur le serveur. En plus d'empecher le client de mettre en cache les attributs des fichiers, l'option noac force l'ecriture synchronisee pour les applications afin que les modifications sur un fichier soient immediatement visibles sur le serveur. De cette facon, les autres clients peuvent rapidement detecter les nouvelles ecritures lors de la verification des attributs du fichier. L'usage de l'option noac offre une plus grande coherence du cache aux clients NFS qui accedent aux memes fichiers, mais au prix d'une penalisation significative des performances. C'est pour cette raison qu'une utilisation judicieuse des verrouillages (<< locking >>) de fichiers est preferable. La section COHERENCE DES DONNEES ET DES METADONNEES contient une presentation detaillee de ces approches. acregmin=n Duree minimale (en seconde) de mise en cache des attributs d'un fichier normal par un client NFS avant leur actualisation depuis le serveur. La valeur par defaut est de 3 secondes si cette option n'est pas definie. Consulter la section COHERENCE DES DONNEES ET DES METADONNEES pour des explications completes sur la mise en cache des attributs. acregmax=n Duree maximale (en seconde) de mise en cache des attributs d'un fichier normal par un client NFS avant leur actualisation depuis le serveur. La valeur par defaut est de 60 secondes si cette option n'est pas definie. Consulter la section COHERENCE DES DONNEES ET DES METADONNEES pour des explications completes sur la mise en cache des attributs. acdirmin=n Duree minimale (en seconde) de mise en cache des attributs d'un repertoire par un client NFS avant leur actualisation depuis le serveur. La valeur par defaut est de 30 secondes si cette option n'est pas definie. Consulter la section COHERENCE DES DONNEES ET DES METADONNEES pour des explications completes sur la mise en cache des attributs. acdirmax=n Duree maximale (en seconde) de mise en cache des attributs d'un repertoire par un client NFS avant leur actualisation depuis le serveur. La valeur par defaut est de 60 secondes si cette option n'est pas definie. Consulter la section COHERENCE DES DONNEES ET DES METADONNEES pour des explications completes sur la mise en cache des attributs. actimeo=n L'utilisation de actimeo configure toutes les durees acregmin, acregmax, acdirmin et acdirmax a la meme valeur. Si cette option n'est pas definie, le client NFS utilisera les valeurs par defaut de chacune des options decrites ci-dessus. bg/fg Determiner le comportement de la commande mount(8) dans le cas d'un echec d'une tentative de montage d'une exportation. L'option fg entraine l'arret de mount(8) avec un etat d'erreur si la moindre partie de la requete de montage depasse le temps alloue ou echoue completement. C'est ce qui est appele un montage en << premier plan >> (pas en mode demon) et c'est le comportement par defaut si ni fg ni bg ne sont indiques. Si l'option bg est indiquee, un depassement du temps alloue ou un echec entrainera la creation d'un enfant (fork) qui continuera a essayer de monter le partage. Le parent s'interrompt immediatement en renvoyant un code de sortie a zero. C'est ce qui est appele un montage en << arriere-plan >> (en mode demon). Si le repertoire servant de point de montage local n'existe pas, la commande mount(8) se comporte comme si la requete etait restee sans reponse (delai depasse). Cela permet aux montages NFS imbriques definis dans /etc/fstab d'etre executes dans n'importe quel ordre lors de l'initialisation du systeme, meme si certains serveurs NFS ne sont pas encore disponibles. On peut aussi gerer ces problemes grace a un automonteur (consulter automount(8) pour plus de details). nconnect=n Lors de l'utilisation d'un protocole oriente connexion tel que TCP, il peut parfois etre avantageux d'etablir plusieurs connexions entre le client et le serveur. Par exemple, si les clients ou les serveurs sont equipes de plusieurs cartes d'interface reseau (NIC), l'utilisation de plusieurs connexions pour repartir la charge peut ameliorer les performances generales. Dans de tels cas, l'option nconnect permet a l'utilisateur de preciser le nombre de connexions a etablir entre le client et le serveur jusqu'a un maximum de 16. Il est a remarquer que l'option nconnect peut aussi etre utilisee par quelques pilotes pNFS pour decider combien de connexions vers les serveurs de donnees sont a utiliser. rdirplus/nordirplus Indiquer s'il faut utiliser les requetes READDIRPLUS de NFS version 3 ou 4. Si cette option n'est pas definie, le client NFS utilisera les requetes READDIRPLUS sur les montages en NFS version 3 ou 4 pour la lecture des petits repertoires. Certaines applications sont plus efficaces si le client n'utilise que des requetes READDIR pour tous les repertoires. retry=n Nombre de minutes pendant lequel le montage NFS sera retente par la commande mount(8), en arriere-plan ou au premier plan, avant d'abandonner. Si cette option n'est pas definie, la valeur par defaut pour le premier plan est de 2 minutes et celle pour l'arriere-plan est 10 000 minutes, soit environ une semaine a 80 minutes pres. La commande mount(8) s'arretera des le premier echec si on lui passe la valeur 0. Il est a remarquer que cela affecte le nombre d'essais effectues, mais n'affecte pas le delai cause par chaque nouvel essai. Pour UDP, chaque essai prend le temps determine par les options timeo et retrans qui par defaut est a peu pres de 7 secondes. Pour TCP il est de 3 minutes, mais les delais d'expiration TCP du systeme peuvent parfois limiter le delai d'expiration de chaque retransmission aux environs de 2 minutes. sec=types Une liste de types de securite, separes pas des deux-points, a utiliser pour acceder aux fichiers de l'exportation montee. Si le serveur ne prend en charge aucun de ces types, l'operation de montage echoue. Si l'option sec= n'est pas indiquee, le client essaie de trouver un type de securite pris en charge a la fois par le client et le serveur. Les types de securite pris en charge sont none, sys, krb5, krb5i et krb5p. Consulter la section CONSIDERATIONS DE SECURITE pour les details. sharecache/nosharecache Determiner comment le client partage ses caches de donnees et d'attributs de fichiers lorsqu'une meme exportation est montee plus d'une fois en meme temps. L'utilisation d'un seul cache reduit les besoins en memoire sur le client et presente aux applications un contenu identique lorsque l'on accede au meme fichier distant par differents points de montage. Si aucune des options n'est indiquee, ou si l'option sharecache est demandee, un seul cache est utilise pour tous les points de montage qui accedent a la meme exportation. Si l'option nosharecache est indiquee, ce point de montage utilise un cache unique. Notez que lorsque les caches des donnees et des attributs sont partages, les options de montage du premier point de montage s'appliquent pour les futurs montages simultanes de cette meme exportation. En ce qui concerne le noyau 2.6.18, le comportement defini par nosharecache est le comportement traditionnel normal. Cela est considere comme dangereux pour les donnees puisque de multiples copies mises en cache du meme fichier sur le meme client peuvent se desynchroniser suite a une mise a jour locale d'une des copies. resvport/noresvport Indiquer si le client NFS doit utiliser un port source privilegie quand il communique avec un serveur NFS pour ce point de montage. Si cette option n'est pas precisee, ou si l'option resvport est precisee, le client NFS utilise un port source privilegie. Si l'option noresvport est activee, le client NFS utilise un port source non privilegie. Cette option est permise par les noyaux 2.6.28 et suivants. Utiliser un port source non privilegie permet d'augmenter le nombre maximal de points de montage permis par client, mais les serveurs NFS doivent etre configures pour permettre la connexion de clients par des ports source non privilegies. Veuillez consulter la section CONSIDERATIONS DE SECURITE pour d'importantes precisions. lookupcache=mode Preciser comment le noyau gere son cache d'entrees de repertoire pour un point de montage donne. mode peut etre all, none, pos ou positive. Cette option est prise en charge par les noyaux 2.6.28 et suivants. Le client NFS Linux garde en cache tous les resultats des requetes NFS LOOKUP. Si l'entree de repertoire recherchee existe sur le serveur, le resultat est considere comme positif, sinon il est considere comme negatif. Si cette option n'est pas precisee, ou si all est precise, le client suppose que les deux types d'entrees (positif ou negatif) du cache de repertoire sont valables jusqu'a ce que les attributs mis en cache de leur repertoire parent expirent. Si pos ou positive est precise, le client suppose que les entrees positives sont valables jusqu'a ce que les attributs mis en cache de leur repertoire parent expirent, mais revalide toujours les entrees negatives avant qu'une application puisse les utiliser. Si none est precise, le client revalide les deux types d'entrees mises en cache de repertoire avant qu'une application puisse les utiliser. Cela permet une detection rapide des fichiers qui ont ete crees ou supprimes par d'autres clients, mais peut avoir des repercussions sur ces applications et les performances du serveur. La partie COHERENCE DES DONNEES ET DES METADONNEES contient des explications detaillees sur ces arbitrages. fsc/nofsc Activer ou desactiver le cache des pages de donnees (en lecture seule) du disque local en utilisant l'outil FS-Cache. Consultez cachefilesd(8) et Documentation/filesystems/caching dans le code source du noyau pour plus de details sur la configuration de l'outil FS-Cache. La valeur par defaut est nofsc. sloppy L'option sloppy est une solution de remplacement pour l'option -s de mount.nfs xprtsec=politique Indiquer l'utilisation d'une securite de la couche transport pour proteger le trafic reseau NFS pour ce point de montage. politique peut etre none, tls ou mtls. Si none est indique, la securite de la couche transport est desactivee, meme si le serveur NFS la gere. Si tls est indique, le client utilise RPC avec TLS pour la confidentialite au cours du transport. Si mtls est indique, le client utilise RPC avec TLS pour s'authentifier lui-meme et pour assurer la confidentialite au cours du transport. Si soit tls ou mtls est indique et que le serveur ne prend pas en charge RPC avec TLS ou que l'authentification de pair echoue, l'essai de montage echoue. Si l'option xprtsec= n'est pas indiquee, le comportement par defaut depend de la version du noyau, mais habituellement est equivalent a xprtsec=none. Options pour les versions NFS 2 et 3 uniquement Utilisez ces options ainsi que les options de la sous-section precedente uniquement pour les systemes de fichiers de type NFS version 2 et 3. proto=idreseau L'identifiant reseau idreseau determine le transport utilise pour communiquer avec le serveur NFS. Les options possibles sont udp, udp6, tcp, tcp6, rdma et rdma6. Les valeurs qui se terminent par 6 utilisent des adresses IPv6 et ne sont disponibles que si la prise en charge de TI-RPC est integree. Les autres utilisent des adresses IPv4. Chaque protocole de transport utilise differents reglages de retrans et de timeo (se referer a la description de ces deux options de montage). En plus de controler la facon dont le client NFS transmet les requetes au serveur, cette option de montage gere aussi la facon dont la commande mount(8) communique avec les services rpcbind et mountd du serveur. Indiquer un ID reseau qui utilise TCP entraine l'utilisation de TCP par tout le trafic passant par la commande mount(8) ou le client NFS. Indiquer un ID reseau qui utilise UDP entraine l'utilisation d'UDP par tous les trafics. Avant d'utiliser NFS sur UDP, consultez la section METHODES DE TRANSPORT. Si l'option proto de montage n'est pas definie, la commande mount(8) decouvrira quels protocoles sont acceptes par le serveur et choisira un transport approprie pour chacun des services. Consultez la section METHODES DE TRANSPORT pour plus de details. udp L'option udp est une solution de remplacement pour proto=udp, incluse pour la compatibilite avec d'autres systemes d'exploitation. Avant d'utiliser NFS sur UDP, consultez la section METHODES DE TRANSPORT. tcp L'option tcp est une solution de remplacement pour proto=tcp, incluse pour la compatibilite avec d'autres systemes d'exploitation. rdma L'option rdma est une solution de remplacement pour proto=rdma. port=n Valeur numerique du port du service NFS sur le serveur. Si le service NFS du serveur n'est pas accessible sur le port indique, la requete de montage echoue. Si cette option n'est pas definie, ou si le port indique est 0, le client NFS utilise le numero du port du service NFS publie par le service rpcbind du serveur. La requete de montage echoue si le service rpcbind du serveur n'est pas accessible, si le service NFS du serveur n'est pas enregistre dans son service rpcbind, ou si le service NFS du serveur n'est pas accessible sur le port publie. mountport=n Valeur numerique du port de mountd sur le serveur. Si le service mountd du serveur n'est pas present sur le port indique, la requete de montage echoue. Si cette option n'est pas definie, ou si le port indique est 0, la commande mount(8) utilise le numero du port du service mountd publie par le service rpcbind du serveur. La requete de montage echoue si le service rpcbind du serveur n'est pas accessible, si le service mountd du serveur n'est pas enregistre dans son service rpcbind ou si le service mountd du serveur n'est pas accessible sur le port publie. Cette option peut etre utilisee pour les montages sur un serveur NFS a travers un pare-feu qui bloque le protocole rpcbind. mountproto=idreseau Le transport utilise par le client NFS pour transmettre ses requetes au service mountd d'un serveur NFS quand il lance cette requete de montage, puis quand il demontera ensuite ce montage. idreseau peut valoir udp ou tcp qui utilisent des adresses IPv4, ou bien, si TI-RPC est integre dans la commande mount.nfs, udp6 ou tcp6 qui utilisent des adresses IPv6. Cette option peut etre utilisee pour monter un serveur NFS a travers un pare-feu qui bloque des transferts specifiques. Lorsqu'elle est utilisee avec l'option proto, differents modes de transfert peuvent etre choisis pour les requetes vers mountd et NFS. Si le serveur ne propose pas de service mountd pour le transfert indique, la requete de montage echoue. Veuillez consulter la section METHODES DE TRANSPORT pour plus de renseignements sur la maniere dont l'option de montage mountproto interagit avec l'option proto. mounthost=nom Le nom d'hote de la machine qui execute le mountd. Si cette option n'est pas definie, la commande mount(8) considere que le service mountd est assure par la machine qui offre le service NFS. mountvers=n Numero de version des RPC utilise pour contacter le demon mountd du serveur. Si cette option n'est pas definie, le client utilise un numero de version approprie a la version de NFS requise. Cette option est utile quand de nombreux services NFS sont offerts par un seul et meme serveur distant. namlen=n La taille maximale d'un composant du nom de chemin de ce montage. Si cette option n'est pas definie, la taille maximale est negociee avec le serveur. Dans la plupart des cas, cette taille maximale est 255 caracteres. Des versions precedentes de NFS ne gerent pas cette negociation. L'utilisation de cette option garantit que pathconf(3) donnera bien la longueur maximale aux applications pour ces versions. lock/nolock Indiquer s'il faut utiliser le protocole auxiliaire NLM pour verrouiller les fichiers sur le serveur. Si aucune option n'est indiquee (ou si c'est lock qui est choisi), le verrouillage NLM est active pour ce point de montage. Si on utilise l'option nolock, les applications peuvent verrouiller les fichiers, mais ces verrous n'excluent que les autres applications qui tournent sur ce meme client. Les applications distantes ne sont pas affectees par ces verrous. Le verrouillage NLM doit etre desactive avec l'utilisation de l'option nolock si /var est monte a l'aide de NFS parce que /var contient des fichiers utilises par l'implementation de NLM sous Linux. L'usage de nolock est aussi requis lors des montages des exportations de serveurs NFS ne gerant pas le protocole NLM. cto/nocto Indiquer s'il faut utiliser la semantique de coherence de cache close-to-open. Si aucune option n'est indiquee (ou si c'est cto qui est indiquee), le client utilise la semantique de coherence de cache close-to-open. Si c'est l'option nocto qui est indiquee, le client utilise une heuristique non standard pour savoir quand les fichiers ont change sur le serveur. L'utilisation de l'option nocto peut ameliorer les performances des montages en lecture seule, mais devrait etre limitee au cas ou les donnees sur le serveur ne changent qu'occasionnellement. La section COHERENCE DES DONNEES ET DES METADONNEES expose le comportement de cette option en details. acl/noacl Indiquer s'il faut utiliser le protocole auxiliaire NFSACL sur ce point de montage. Le protocole auxiliaire NFSACL est un protocole proprietaire mis en oeuvre dans Solaris et qui gere les listes de controle d'acces (ACL). NSFACL n'est jamais devenu un element standard de la specification du protocole NFS. Si ni acl ni noacl ne sont precisees, le client NFS negocie avec le serveur afin de savoir si le protocole NFSACL est gere et l'utilise dans ce cas. La desactivation du protocole auxiliaire NFSACL est parfois rendue necessaire quand la negociation pose des problemes sur le client ou sur le serveur. Consultez la section CONSIDERATIONS DE SECURITE pour plus de details. local_lock=mecanisme Indiquer si le verrouillage local doit etre utilise pour les mecanismes de verrouillage flock, POSIX ou pour les deux. mecanisme peut etre all, flock, posix ou none. Cette option est prise en charge par les noyaux 2.6.37 et suivants. Le client Linux NFS fournit un moyen de poser des verrous locaux. Les applications peuvent donc verrouiller des fichiers, mais ces verrous n'excluent que les autres applications qui tournent sur ce meme client. Les applications distantes ne sont pas affectees par ces verrous. Si cette option n'est pas precisee, ou si none est precise, le client suppose que les verrous ne sont pas locaux. Si all est specifie, le client suppose que les deux types de verrous flock et POSIX sont locaux. Si flock est specifie, le client suppose que seuls les verrous flock sont locaux, et utilise le protocole NLM auxiliaire pour verrouiller les fichiers quand les verrous POSIX sont utilises. Si posix est specifie, le client suppose que les verrous POSIX sont locaux, et utilise le protocole NLM auxiliaire pour verrouiller les fichiers quand les verrous flock sont utilises. Pour prendre en charge le comportement patrimonial de flock de facon semblable a celui des clients NFS < 2.6.12, il faut utiliser << local_lock=flock >>. Cette option est requise lors de l'exportation des montages NFS a l'aide de Samba car Samba mappe les verrous du mode partage de Windows comme flock. Puisque les clients NFS > 2.6.12 implementent flock en emulant les verrous POSIX, cela aboutira a un conflit de verrous. NOTE : quand elles sont utilisees ensemble, l'option de montage << local_lock >> sera ecrasee par les options de montage << nolock >>/<< lock >>. Options pour NFS version 4 uniquement Ces options sont a utiliser ainsi que les options de la premiere sous-section ci-dessus pour les systemes de fichiers de type NFS version 4 et plus recents. proto=idreseau L'identifiant reseau idreseau determine le transport utilise pour communiquer avec le serveur NFS. Les options possibles sont tcp, tcp6, rdma et rdma6. L'option tcp6 utilise des adresses IPv6 et n'est disponible que si la prise en charge de TI-RPC est integree. Les autres options utilisent des adresses IPv4. Les serveurs NFS version 4 doivent prendre en charge TCP, donc si cette option de montage n'est pas precisee, le client NFS version 4 utilise le protocole TCP. Veuillez vous referer a la section METHODES DE TRANSPORT pour plus de details. minorversion=n Indiquer le numero mineur de version du protocole. NFS 4 a introduit le << versionnage mineur >> ou des ameliorations du protocole NFS peuvent etre introduites sans toucher son numero de version. Avant le noyau 2.6.38, la version mineure etait toujours zero et cette option n'est par reconnue. Apres ce noyau, indiquer << minorversion=1 >> active des fonctions avancees comme les sessions NFSv4. Les noyaux recents permettent d'indiquer une version mineure en utilisant l'option vers=. Par exemple, indiquer vers=4.1 a le meme effet que vers=4,minorversion=1. port=n Valeur numerique du port du service NFS sur le serveur. Si le service NFS du serveur n'est pas accessible sur le port indique, la requete de montage echoue. Si cette option de montage n'est pas definie, le client NFS utilisera le numero de port standard de NFS (2049) sans verifier de prime abord le service rpcbind du serveur. Cette option permet a un client NFS version 4 de contacter un serveur NFS version 4 a travers un pare-feu qui bloquerait les requetes rpcbind. Si la valeur du port indiquee est 0, le client NFS utilisera le numero de port du service NFS publie par le service rpcbind du serveur. La requete de montage echouera si le service rpcbind du serveur n'est pas disponible, si le service NFS du serveur n'est pas enregistre dans son service rpcbind ou si le service NFS du serveur n'est pas accessible sur le port publie. cto/nocto Indiquer s'il faut utiliser la semantique de coherence du cache close-to-open pour les repertoires NFS de ce point de montage. Si ni cto ni nocto ne sont indiquees, la semantique de coherence du cache close-to-open sera utilisee par defaut pour les repertoires. La politique de mise en cache des donnees des fichiers n'est pas concernee par cette option. La section COHERENCE DES DONNEES ET DES METADONNEES decrit le comportement de cette option en details. clientaddr=n.n.n.n clientaddr=n:n:...:n Indiquer une seule adresse IPv4 (quadruplet separe par des points) ou une adresse IPv6 qui n'est pas un lien local que le client NFS signalera pour permettre aux serveurs d'envoyer des requetes de rappel NFS version 4.0 sur les fichiers de ce point de montage. Si le serveur ne peut pas etablir de connexion de rappel (<< callback >>) sur ces clients, les performances peuvent etre degradees ou les acces a ces fichiers temporairement suspendus. Une valeur IPv4_ANY (0.0.0.0) ou n'importe quelle adresse IPv6 equivalente peut etre indiquee qui signalera au serveur NFS que ce client NFS ne veut pas de delegations. Si cette option n'est pas indiquee, la commande mount(8) essaie de decouvrir automatiquement une adresse de rappel (<< callback >>) appropriee. La procedure de decouverte automatique n'est cependant pas parfaite. Dans le cas d'interfaces reseau multiples, de directives de routages speciales ou de typologie reseau atypique, l'adresse exacte a utiliser pour les rappels peut ne pas etre triviale a determiner. Les versions 4.1 et 4.2 du protocole NFS utilisent la connexion TCP etablie par le client pour les requetes de rappel, donc ne requierent pas au serveur de se connecter au client. Cette option affecte par consequent seulement les montages NFS version 4.0. migration/nomigration Choisir si le client utilise une chaine d'authentification qui est compatible avec TSM (Transparent State Migration) pour NFSv4. Si le serveur monte prend en charge la migration de NFSv4 avec TSM, indiquer l'option migration. Certaines fonctions de serveur se comportent mal face a la chaine d'authentification compatible avec la migration. L'option nomigration conserve l'utilisation de la chaine d'authentification traditionnelle qui est compatible avec les serveurs NFS patrimoniaux. C'est aussi le comportement si aucune option n'est indiquee. Un etat ouvert et verrouille d'un client ne peut etre migre de maniere transparente quand il s'identifie lui-meme avec une chaine d'identification traditionnelle. Cette option de montage n'a aucun effet avec les versions mineures de NFSv4 plus recentes que zero, qui utilisent des chaines d'identification compatibles avec TSM. max_connect=n Alors que l'option nconnect definit une limite du nombre de connexions pouvant etre etablies sur une adresse IP de serveur donnee, l'option max_connect permet a l'utilisateur d'indiquer le nombre maximal de connexions vers des adresses IP de serveur differentes qui appartiennent au meme serveur NFSv4.1+ (connexions de session simultanees) jusqu'a une limite de 16. Quand le client decouvre que cela etablit un ID de client a un serveur deja existant, au lieu d'abandonner le transport reseau nouvellement cree, le client ajoute cette nouvelle connexion a la liste des transports disponibles pour ce client RPC. trunkdiscovery/notrunkdiscovery Quand un client decouvre un nouveau systeme de fichiers sur un serveur NFSv4.1+, l'option de montage trunkdiscovery fera qu'il enverra un GETATTR pour l'attribut fs_locations. S'il recoit une reponse de longueur non nulle, il iterera a travers la reponse et pour chaque emplacement de serveur il etablira une connexion, enverra un EXCHANGE_ID et testera le << trunking >> de session. Si le test de << trunking >> reussit, la connexion sera ajoutee a l'ensemble existant des transports pour le serveur, en respectant la limite indiquee par l'option max_connect. La valeur par defaut est notrunkdiscovery. SYSTEME DE FICHIERS DE TYPE nfs4 Le type nfs4 de systeme de fichiers est une ancienne syntaxe precisant l'utilisation de NFSv4. Il peut toujours etre utilise avec toutes les options communes et avec celles specifiques a NFSv4, a l'exception de l'option de montage nfsvers FICHIER DE CONFIGURATION DU MONTAGE Si la commande de montage est configuree en ce sens, toutes les options de montage decrites dans la section precedente peuvent etre configurees dans le fichier /etc/nfsmount.conf. Referez-vous a nfsmount.conf(5) pour plus de details. EXEMPLES Pour realiser un montage NFS version 3, le type de systeme de fichiers a utiliser est nfs et l'option de montage nfsvers=3 doit etre indiquee. Pour realiser un montage NFS version 4, le type de systeme de fichiers a utiliser est soit nfs avec l'option de montage nfsvers=4 ou le type nfs4. L'exemple de fichier /etc/fstab suivant permet a la commande de montage de negocier des valeurs par defaut convenables pour le comportement de NFS. serveur:/export /mnt nfs defaults 0 0 Cet exemple montre comment realiser un montage NFS version 4 a travers TCP, utilisant l'authentification mutuelle avec Kerberos 5. serveur:/export /mnt nfs4 sec=krb5 0 0 Cet exemple montre comment realiser un montage NFS version 4 a travers TCP, avec le mode prive de Kerberos 5 ou celui d'integrite des donnees. serveur:/export /mnt nfs4 sec=krb5p:krb5i 0 0 Cet exemple peut servir a realiser le montage de /usr par NFS. serveur:/export /usr nfs ro,nolock,nocto,actimeo=3600 0 0 Cet exemple montre comment monter un serveur NFS en utilisant une adresse brute link-local IPv6. [fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0 METHODES DE TRANSPORT Les clients NFS envoient leurs requetes aux serveurs NFS grace aux appels de procedures distantes (<< Remote Procedure Calls >>), les RPCs. Le client RPC decouvre automatiquement les terminaisons d'acces du service distant, gere l'authentification par requete, ajuste les parametres des requetes afin de gerer l'ordre des octets sur le client et le serveur (<< endianness >>) et se charge de la retransmission des requetes qui pourraient s'etre perdues dans le reseau ou sur le serveur. Les requetes et les reponses RPC circulent sur un transport reseau. Dans la plupart des cas, la commande mount(8), le client NFS et le serveur NFS peuvent negocier automatiquement les transports adaptes et la taille de donnees adequate pour les transferts pour un point de montage. Cependant, dans certains cas, il peut etre benefique d'indiquer explicitement ces reglages grace aux options de montage. Traditionnellement, les clients NFS se servaient uniquement du transport UDP pour transmettre des requetes aux serveurs. Bien que son implementation soit simple, NFS sur UDP a de nombreuses limitations qui l'empechent d'obtenir de bonnes performances et un fonctionnement fluide dans certains environnements de deploiement courants. Un taux de paquets perdus meme insignifiant entraine la perte de requetes NFS completes. On regle alors generalement le delai de depassement (<< timeout >>) a une valeur inferieure a la seconde afin que les clients puissent recuperer rapidement en cas de requetes rejetees. Cela peut entrainer une surcharge du trafic reseau et du serveur. Cependant, UDP peut etre assez efficace grace a des reglages specifiques lorsque le MTU du reseau depasse la taille de transfert de donnees de NFS (par exemple dans les environnements reseau qui utilisent les trames Ethernet Jumbo). Dans ces cas, il est judicieux d'adapter les reglages rsize et wsize de facon a ce que chaque requete de lecture ou d'ecriture NFS soit contenue dans quelques trames du reseau (voire meme dans une seule trame). Cela reduit la probabilite qu'une perte d'une simple trame reseau de la taille de la MTU entraine la perte complete d'un grande requete en lecture ou ecriture. TCP est le protocole de transport utilise par defaut dans toutes les implementations modernes de NFS. Il est efficace dans pratiquement tous les environnements reseau concevables et offre d'excellentes garanties contre la corruption de donnees que pourrait entrainer un incident reseau. TCP est souvent obligatoire pour acceder a un serveur a travers un pare-feu. Dans des conditions normales, les reseaux rejettent des paquets bien plus souvent que les serveurs NFS ne rejettent de requetes. C'est pourquoi un reglage agressif de delai de depassement (<< time-out >>) de retransmission pour NFS sur TCP est inutile. Les reglages habituels de delai de depassement pour NFS sur TCP varient entre une et dix minutes. Apres qu'un client a termine ses retransmissions (la valeur de l'option retrans de montage), il considere que le reseau a subi un cloisonnement et tente de se reconnecter au serveur sur un nouveau socket. Puisque TCP rend fiable le transport de donnees sur le reseau, rsize et wsize peuvent en toute securite prendre pour valeur par defaut la plus grande valeur geree a la fois par le client et par le serveur, independamment de la taille du MTU du reseau. Utilisation de l'option de montage mountproto Cette section s'applique uniquement aux versions 2 et 3 de montages NFS car NFS 4 n'utilise pas un protocole different pour les requetes de montage. Le client Linux de NFS peut utiliser differents modes de transport pour contacter le service rpcbind d'un serveur NFS, son service mountd, son gestionnaire de verrous reseau (NLM - Network Lock Manager) et son service NFS. Le mode exact de transport utilise par le client Linux de NFS pour chaque point de montage depend des reglages des options de transport de montage, qui incluent proto, mountproto udp et tcp. Le client envoie des notifications au gestionnaire d'etat reseau (NSM : Network Status Manager) a l'aide d'UDP, quel que soit le mode de transport precise. Il ecoute cependant les notifications NSM du serveur a la fois sur UDP et TCP. Le protocole gerant la liste de controles d'acces a NFACL (NFS Access Control List) utilise le meme mode de transport que le service NFS principal. Si aucune option n'est precisee quant au mode de transport, le client Linux de NFS utilise UDP pour contacter le service mountd du serveur et TCP pour contacter ses services NLM et NFS par defaut. Si le serveur ne gere pas ces modes de transfert pour ces services, la commande mount(8) essaye de trouver quel mode est pris en charge par le serveur et essaye une fois de se reconnecter avec ce mode. Si le serveur ne propose aucun mode gere par le client ou est mal configure, la requete de montage echoue. Si l'option bg a ete passee, la commande de montage passe en arriere-plan et continue d'essayer la requete de montage demandee. Quand l'une des options proto, udp ou tcp est passee mais que mountproto ne l'est pas, le mode de transfert demande est utilise a la fois pour contacter le service mountd du serveur et ses services NLM et NFS. Si l'option mountproto est passee mais que ni proto, ni udp et ni tcp n'est passee alors le mode demande est utilise pour la requete de montage initiale, mais la commande de montage essaye de decouvrir quel mode de transfert est pris en charge pour le protocole NFS, et preferera TCP si les deux modes sont implementes. Si mountproto et proto (ou udp ou tcp) sont passes en meme temps, le mode de transport indique par l'option mountproto est utilise pour la requete initiale de mountd et le mode indique par l'option proto (ou udp ou tcp) est utilise pour NFS quel que soit l'ordre de ces options. Aucune decouverte automatique de service n'est faite si ces options sont passees. Si l'une des options proto, udp, tcp ou mountproto est passee plus d'une fois dans une meme ligne de commande de montage, l'instance la plus a droite de chacune de ces options prendra effet. Utiliser NFS sur UDP sur des connexions haut debit Utiliser NFS sur UDP avec des connexions haut debit comme Gigabit peut causer silencieusement des corruptions de donnees. Le probleme peut etre declenche lors de fortes charges et est cause par des difficultes dans le reassemblage de fragments IP. Les lectures et ecritures par NFS transmettent typiquement des paquets UDP de 4 kilooctets ou plus, qui doivent etre casses en plusieurs fragments pour etre envoyes sur le lien Ethernet pour lequel la taille des paquets est limitee a 1 500 octets par defaut. Ce processus a lieu au niveau de la couche reseau IP et est appele fragmentation. Afin d'identifier les fragments qui proviennent du meme paquet, IP attribue un identifiant IP (IP ID) sur 16 bits a chaque paquet. Les fragments generes a partir du meme paquet UDP auront le meme identifiant IP. Le systeme destinataire recupere ces fragments et les combine pour reformer les paquets UDP originaux. Ce processus est appele reassemblage. Le delai d'expiration par defaut pour le reassemblage de paquets est de 30 secondes. Si la pile reseau ne recoit pas tous les fragments d'un paquet donne pendant cet intervalle de temps, elle suppose que les fragments manquants se sont perdus et rejette ceux qui ont deja ete recus. Le probleme que cela cree sur des connexions a haut debit est du au fait qu'il est possible d'envoyer plus de 655 356 paquets en 30 secondes. En fait, avec un trafic dense NFS, les identifiants IP se repetent au bout d'environ 5 secondes. Cela a de serieux effets sur le reassemblage : si un fragment se perd, un autre fragment d'un paquet different mais avec le meme identifiant IP arrivera avant l'expiration au bout de 30 secondes et la pile reseau combinera ces fragments pour former un nouveau paquet. La plupart du temps, les couches reseau au-dessus d'IP detecteront ce reassemblage non assorti -- dans le cas d'UDP, la somme de controle UDP sur 16 bits sur la charge utile complete du paquet ne correspondra pas et UDP rejettera le mauvais paquet. Cependant, comme la somme de controle UDP est seulement sur 16 bits, il y a une chance sur 65 536 qu'elle coincide meme si la charge utile du paquet est completement aleatoire (ce qui tres souvent n'est pas vrai). Si tel est le cas, une corruption de donnees silencieuse sera produite. Cette possibilite doit etre prise au serieux, au moins sur Gigabit Ethernet. Les debits reseau de 100 Mbit/s peuvent etre consideres comme moins problematiques, car dans la plupart des situations, la reinitialisation des identifiants IP prendra bien plus que 30 secondes. Il est donc fortement recommande d'utiliser NFS sur TCP la ou c'est possible car TCP n'effectue pas de fragmentation. Si vous devez absolument utiliser NFS sur UDP sur un reseau Gigabit Ethernet, quelques actions peuvent etre effectuees pour limiter le probleme et reduire la probabilite de corruption : trames Jumbo De nombreuses cartes reseau Gigabit sont capables de transmettre des trames plus grandes que la limite traditionnelle sur Ethernet de 1 500 octets (typiquement 9 000 octets). Utiliser ces grandes trames (Jumbo) vous permettra de faire fonctionner NFS sur UDP avec une taille de page de 8 ko sans fragmentation. Bien sur, cela n'est possible que si toutes les stations impliquees gerent les trames Jumbo. Pour activer l'envoi de trames Jumbo sur une machine avec une carte reseau qui les gere, il suffit de configurer l'interface avec une valeur MTU de 9000. diminution du delai avant expiration du reassemblage Le reassemblage incorrect de fragments peut etre aussi evite en diminuant ce delai sous le temps necessaire a la reinitialisation des identifiants IP. Pour ce faire, ecrivez simplement la nouvelle valeur du delai (en seconde) dans le fichier /proc/sys/net/ipv4/ipfrag_time. Une valeur de 2 secondes diminuera fortement la probabilite d'une collision d'identifiants IP sur une seule liaison Gigabit, tout en permettant un delai d'expiration raisonnable lors de la reception d'un trafic fragmente depuis des serveurs distants. COHERENCE DES DONNEES ET DES METADONNEES Certains systemes de fichiers modernes pour les grappes (cluster) offrent une coherence absolue du cache a leurs clients. La coherence parfaite de cache pour des clients NFS heterogenes est difficile a obtenir, surtout sur les reseaux de grandes tailles. Dans ce cas, NFS adopte une coherence de cache plus faible qui satisfait les contraintes de la plupart des types de partage de fichiers. Coherence de cache << close-to-open >> Classiquement, le partage de fichier est completement sequentiel. Le client A ouvre d'abord un fichier, y ecrit quelque chose et le referme. Puis le client B ouvre le meme fichier et lit les modifications. Quand une application ouvre un fichier stocke sur un serveur NFS version 3, le client NFS verifie que le fichier existe sur le serveur et est accessible a cette application en envoyant une requete GETATTR ou ACCESS. Le client NFS envoie ces requetes sans tenir compte de l'anciennete des attributs de fichier mis en cache. Quand l'application ferme le fichier, le client NFS y ecrit toutes les modifications en attente afin que le prochain client ouvrant ce fichier puisse en voir les changements. Cela donne l'opportunite au client NFS de prevenir l'application de toute erreur en ecriture sur le serveur grace au code de retour de close(2). Le comportement consistant a verifier au moment de l'ouverture et a vider a la fermeture est appele close-to-open cache consistency (consistance de cache close-to-open) ou CTO. Il peut etre desactive en entier pour un point de montage en utilisant l'option de montage nocto. Faible coherence de cache Il y a toujours des cas dans lesquels le cache de donnees du client contient des donnees incoherentes. Dans la version 3 du protocole NFS est apparue la << faible coherence de cache >> (appelee aussi WCC - weak cache consistency), offrant une methode efficace de verification des attributs d'un fichier avant et apres une requete unique. Cela permet a un client une meilleure perception des modifications qui ont pu etre realisees par les autres clients. Quand un client genere de nombreuses operations concomitantes qui modifient le meme fichier au meme moment (par exemple lors d'ecritures asynchrones en arriere-plan), il est difficile de savoir si le fichier a ete modifie par ce client ou par un autre. Mise en cache des attributs L'utilisation de l'option de montage noac permet de realiser la coherence de la mise en cache des attributs pour de multiples clients. Pratiquement toutes les operations de systeme de fichiers verifient les informations d'attributs de fichiers. Le client garde cette information en cache pendant un certain temps afin de reduire la charge du serveur et du reseau. Quand noac est activee, le cache des attributs de fichier est desactive sur le client et chaque operation qui doit verifier les attributs des fichiers doit imperativement s'adresser au serveur. Cela permet au client de voir rapidement les modifications sur un fichier, en contrepartie d'une augmentation importante des operations sur le reseau. Soyez attentif a ne pas confondre l'option noac avec << pas de mise en cache des donnees >>. L'option de montage noac empeche la mise en cache par le client des metadonnees du fichier, mais il existe toujours des cas dans lesquels des incoherences de donnees en cache peuvent survenir entre le client et le serveur. Le protocole NFS n'a pas ete concu pour gerer la coherence absolue des caches de systemes de fichiers dans des grappes sans qu'il soit necessaire d'utiliser des types particuliers de serialisation au niveau applicatif. Si la coherence absolue du cache est necessaire aux clients, les applications devront utiliser le verrouillage de fichiers. Comme solution de remplacement, les applications pourront aussi utiliser le drapeau O_DIRECT lors de l'ouverture des fichiers afin de desactiver totalement la mise en cache des donnees. Entretien des horodatages de fichier Les serveurs NFS sont responsables de la gestion des horodatages de fichier et de repertoire (atime, ctime et mtime). Quand un fichier est accede ou mis a jour sur un serveur NFS, ses horodatages sont mis a jour comme ils le seraient sur un systeme de fichiers local pour une application. Les clients NFS mettent en cache les attributs de fichier, horodatages inclus. Les horodatages de fichier sont mis a jour quand les attributs sont recuperes a partir du serveur NFS. Par consequent, un certain delai peut exister avant que les mises a jour d'horodatage sur un serveur NFS apparaissent aux applications sur les clients NFS. Pour se conformer aux normes de systeme de fichiers POSIX, le client Linux NFS se fie aux serveurs NFS pour conserver correctement a jour les horodatages mtime et ctime. Il realise cela en vidant les changements locaux de donnees sur le serveur avant de rapporter mtime aux applications a l'aide d'appels systeme tels que stat(2). Le client Linux gere les mises a jour de atime plus grossierement. Les clients NFS entretiennent des bonnes performances en mettant en cache les donnees, mais cela signifie que les lectures d'application, qui normalement mettent a jour atime, ne sont pas reportees sur le serveur ou l'atime du fichier est reellement entretenu. A cause de ce comportement de mise en cache, le client Linux de NFS ne prend pas en charge les options generiques de montage relatives a atime. Consulter mount(8) pour plus de details sur ces options. En particulier, les options de montage atime/noatime, diratime/nodiratime, relatime/norelatime et strictatime/nostrictatime n'ont aucun effet sur les montages NFS. /proc/mounts peut rapporter que l'option de montage relatime est definie sur les montages NFS, mais en fait les semantiques de atime sont toujours comme decrit ici et ne sont pas comme les semantiques de relatime. Mise en cache des entrees de repertoire Le client Linux de NFS garde en cache le resultat de toutes les requetes NFS LOOKUP. Si l'entree de repertoire demandee existe sur le serveur, le resultat de recherche est considere comme positif. Sinon, si l'entree n'existe pas (c'est-a-dire si le serveur retourne ENOENT), le resultat de recherche sera considere comme negatif. Afin de detecter l'ajout ou la suppression d'entrees de repertoire sur le serveur, le client Linux de NFS regarde la date de modification (<< mtime >>) du repertoire. Si le client detecte un changement dans cette date, le client supprime tous les resultats LOOKUP encore en cache concernant ce repertoire. Comme la date de modification est un attribut conserve en cache, il est possible qu'un peu de temps se passe avant que le client remarque le changement. Referez-vous aux descriptions des options de montage acdirmin, acdirmax et noac pour plus d'informations quant a la maniere dont la date de modification est mise en cache. Mettre en cache les entrees de repertoire ameliore les performances des applications qui ne partagent pas de fichiers avec des applications sur d'autres clients. Cependant, l'utilisation d'informations en cache sur des repertoires peut interferer avec des applications qui tournent simultanement sur de nombreux clients et qui doivent detecter rapidement la creation ou la suppression de fichiers. L'option de montage lookupcache permet de personnaliser certains comportements de mise en cache d'entree de repertoire. Avant la version 2.6.28 du noyau, le client Linux de NFS cherchait uniquement les resultats de recherche positifs. Cela permettait aux applications de detecter rapidement de nouvelles entrees de repertoire creees par d'autres clients, tout en conservant une partie des benefices dus a la mise en cache. Si une application depend de cet ancien comportement, vous pouvez utiliser l'option lookupcache=positive. Si le client ignore son cache et valide toutes les requetes de recherche d'application avec le serveur, il peut alors detecter immediatement toute creation ou suppression d'entree de repertoire par un autre client. Vous pouvez forcer ce comportement avec l'option lookupcache=none. L'absence de mise en cache d'entrees de repertoire exige une augmentation du nombre de requetes NFS, et donc une perte de performances. Empecher la recherche sur le cache devrait permettre une moindre perte au niveau des performances que d'utiliser noac, et n'a aucun effet sur la maniere dont le client NFS met en cache les attributs d'un fichier. Option de montage sync Le client NFS gere l'option de montage sync differemment d'autres systemes de fichiers (consulter mount(8) pour une description generique des options de montage sync et async). Si ni sync ni async ne sont indiquees (ou si l'option async est indiquee), le client NFS retarde l'envoi au serveur des ordres d'ecriture des applications jusqu'a ce que l'un de ces evenements survienne : La saturation en memoire entraine une demande de ressources memoire au systeme. Une application met a jour (<< flush >>) les donnees d'un fichier de maniere explicite avec sync(2), msync(2) ou fsync(3). Une application ferme un fichier avec close(2). Le fichier est verrouille/deverrouille grace a fcntl(2). Autrement dit, dans les conditions normales d'utilisation, des donnees ecrites par une application peuvent ne pas apparaitre instantanement sur le serveur qui heberge le fichier. Si l'option sync est precisee pour un point de montage, tout appel systeme qui ecrit des donnees dans des fichiers de ce point de montage entraine le vidage des donnees sur le serveur avant de revenir en espace utilisateur. Cela offre une meilleure coherence du cache des donnees entre les clients, mais a un impact certain sur les performances. Les applications peuvent utiliser le drapeau d'ouverture O_SYNC afin que les applications ecrivent dans des fichiers individuels pour etre immediatement pris en compte par le serveur sans avoir a utiliser l'option de montage sync. Utilisation des verrous de fichier avec NFS Le Gestionnaire de Verrous Reseaux (NLM, Network Lock Manager) est un protocole auxiliaire distinct servant a gerer les verrous sur les fichiers dans la versions 3 de NFS. Pour gerer la recuperation des verrous apres le redemarrage d'un client ou du serveur, un second protocole (connu sous le nom de protocole Network Status Manager) est necessaire. Dans la version 4 de NFS, le verrouillage des fichiers est directement pris en charge dans le protocole NFS et les protocoles NLM et NSM ne sont plus utilises. Dans la plupart des cas, les services NLM et NSM sont demarres automatiquement et aucune configuration additionnelle n'est requise. La configuration en noms de domaine pleinement qualifies (FQDN) de tous les clients NFS est necessaire pour permettre aux serveurs NFS de retrouver leurs clients pour les informer des redemarrages de serveur. NLM ne gere que les verrous partages de fichier. Pour verrouiller les fichiers NFS, il faut utiliser fcntl(2) avec les commandes F_GETLK et F_SETLK. Le client NFS convertit les verrous de fichiers obtenus grace a flock(2) en verrous partages. Lors du montage de serveurs ne gerant pas le protocole NLM ou lorsqu'on monte un serveur NFS a travers un pare-feu qui bloque le port du service NLM, il faut utiliser l'option nolock de montage. Le verrouillage NLM doit etre desactive grace a l'option nolock lorsqu'on utilise NFS pour monter /var, puisque /var contient les fichiers utilises par NLM dans son implementation sous Linux. L'utilisation de l'option nolock est parfois conseillee pour ameliorer les performances d'une application proprietaire qui ne tourne que sur un seul client, mais qui utilise intensement les verrous de fichiers. Caracteristiques du cache de la version 4 de NFS. Le comportement du cache des donnees et des metadonnees des clients NFS version 4 est identique a celui des versions precedentes. Toutefois, la version 4 de NFS offre deux nouveaux dispositifs pour ameliorer le comportement du cache : attributs de changement et delegation de fichier. L'attribut de changement est un nouvel element des metadonnees de fichiers et de repertoires NFS qui enregistre les modifications des donnees. Il se substitue a l'utilisation de l'horodatage des modifications et changements du fichier pour permettre aux clients de valider le contenu de leurs caches. Cependant, ces attributs de changement ne sont pas lies a la gestion de l'horodatage ni sur le client ni sur le serveur. La delegation de fichier est un contrat qui lie un client NFS version 4 et le serveur, permettant temporairement au client de traiter un fichier comme s'il etait le seul a y acceder. Le serveur s'engage a prevenir le client (grace a une requete de rappel, ou << callback >>) si un autre client tente d'acceder a ce meme fichier. Lorsqu'un fichier a ete delegue a un client, ce client peut memoriser (mettre en cache) les donnees et les metadonnees de ce fichier de facon agressive sans avoir a contacter le serveur. Il y a deux types de delegations : lecture et ecriture. Une delegation en lecture indique que le serveur avertira le client si d'autres clients veulent ecrire dans ce fichier. Une delegation en ecriture indique que le client sera prevenu des tentatives de lecture ou d'ecriture. Les serveurs accordent les delegations de fichier sitot qu'un fichier est ouvert et peuvent annuler ces delegations n'importe quand des lors qu'un autre client desire acceder a un fichier d'une maniere qui entre en conflit avec les delegations deja attribuees. Les delegations de repertoire ne sont pas gerees. Afin de pouvoir gerer les alertes de delegations (<< delegation callback >>), le serveur verifie le chemin retour vers le client au moment du contact initial de celui-ci avec le serveur. Si le contact avec le client ne peut pas etre etabli, le serveur n'attribue purement et simplement aucune delegation a ce client. CONSIDERATIONS DE SECURITE. Les serveurs NFS controlent l'acces aux donnees des fichiers, mais leur offre de gestion de l'authentification des requetes NFS depend de leur implementation des RPC. Les controles d'acces NFS traditionnels imitent les controles d'acces binaires standards offerts par les systemes de fichiers locaux. L'authentification RPC traditionnelle utilise un nombre pour representer chaque utilisateur (normalement l'UID propre a cet utilisateur), un nombre pour representer le groupe de cet utilisateur (le GID de l'utilisateur) et un ensemble d'au maximum 16 nombres de groupes additionnels pour representer les autres groupes auxquels cet utilisateur peut appartenir. Traditionnellement, les donnees du fichier et l'ID de l'utilisateur ne sont pas chiffres sur le reseau (c'est-a-dire apparaissent en clair). Qui plus est, les versions 2 et 3 de NFS utilisent des protocoles auxiliaires differents pour le montage, le verrouillage et le deverrouillage des fichiers et pour renvoyer les valeurs de retour systeme des clients et serveurs. Ces protocoles auxiliaires n'utilisent pas d'authentification. En plus d'avoir integre ces deux protocoles auxiliaires dans le protocole NFS principal, la version 4 de NFS offre des formes plus avancees de controle d'acces, d'authentification et de protection lors du transfert des donnees. La specification de la version 4 de NFS requiert une prise en charge de l'authentification renforcee et de types de securite permettant le controle d'integrite et le chiffrement par appel RPC. Puisque la version 4 de NFS ajoute les fonctionnalites de ces protocoles auxiliaires au coeur du protocole NFS, les nouvelles caracteristiques de securite s'appliquent a toutes les operations de NFS version 4, incluant donc le montage, le verrouillage des fichiers, etc. L'authentification RPCGSS peut aussi etre utilisee avec les versions 2 et 3 de NFS, mais ne protege pas leurs protocoles auxiliaires. L'option de montage sec indique quel type de securite est utilise sur ce point de montage NFS pour un utilisateur. L'ajout de sec=krb5 fournit la verification par chiffrement de l'identite de l'utilisateur pour chaque requete RPC. Ce dispositif offre une verification forte de l'identite des utilisateurs qui accedent aux donnees du serveur. Notez qu'une configuration supplementaire a cet ajout d'option de montage est necessaire pour activer la securite Kerberos. Consulter la page de manuel de rpc.gssd(8) pour plus de details. Deux types supplementaires de securite Kerberos sont pris en charge : krb5i et krb5p. Le dispositif de securite krb5i offre une garantie de chiffrement fort contre la falsification des donnees pour chaque requete RPC. Le dispositif de securite krb5p chiffre chaque requete RPC afin d'eviter qu'elle soit exposee pendant son transfert sur le reseau. Toutefois, le chiffrement ou la verification de l'integrite entrainent des baisses de performance. D'autres formes de securite par chiffrement sont aussi prises en charge. Traversee de systemes de fichiers NFS version 4 Le protocole de la version 4 de NFS permet a un client de renegocier le type de securite lorsqu'un client passe sur un nouveau systeme de fichiers sur le serveur. Le type nouvellement negocie ne concerne que le nouveau systeme de fichiers. Une telle negociation se produit typiquement lorsqu'un client passe d'un pseudo-systeme de fichiers du serveur a un des systemes de fichiers physiques exportes par le serveur, qui ont souvent des parametres de securite plus restrictifs que les pseudo-systemes de fichiers. Baux de NFS version 4 Dans NFS version 4, un bail est une periode pendant laquelle un serveur accorde irrevocablement a un client des verrous de fichier. Une fois le bail expire, le serveur peut revoquer ces verrous. Les clients renouvellent periodiquement leurs baux pour eviter la revocation du verrou. Apres redemarrage d'un serveur NFS version 4, chaque client indique au serveur l'etat d'ouverture et de verrouillage du fichier existant sous son bail avant que l'operation puisse continuer. Si un client redemarre, le serveur libere tous les etats ouvert et verrouille associes au bail du client. Par consequent, lors de l'etablissement d'un bail, un client doit s'authentifier de lui-meme aupres d'un serveur. Chaque client presente une chaine arbitraire pour se distinguer des autres clients. L'administrateur de clients peut completer la chaine d'identite par defaut en utilisant le parametre de module nfs4.nfs4_unique_id pour eviter des collisions avec des chaines d'identite d'autres clients. Un client utilise aussi un type unique de securite et un commettant quand il etablit son bail. Si deux clients presentent deux chaines d'identite identiques, un serveur peut utiliser les commettants de client pour faire la distinction, donc empechant de maniere securisee qu'un client interfere avec un autre bail. Le client etablit un bail sur chaque serveur NFS version 4. Les operations de gestion de bail, telles que le renouvellement de bail, ne sont pas faites pour le compte d'un fichier, d'un verrou, d'un utilisateur ou d'un point de montage particuliers, mais pour le compte du client titulaire de ce bail. Un client utilise une chaine d'identite, un type de securite et un commettant coherents a travers les redemarrages de client pour assurer que le serveur puisse promptement connaitre l'etat d'expiration des baux. Quand Kerberos est configure sur un client Linux NFS (c'est-a-dire qu'il existe un /etc/krb5.keytab sur ce client), le client essaie d'utiliser le type Kerberos de securite pour les operations de gestion de bail. Kerberos fournit l'authentification securisee pour chaque client. Par defaut, le client utilise host/ ou le commettant du service nfs/ dans son /etc/krb5.keytab dans ce but comme decrit dans rpc.gssd(8). Si le client a Kerberos configure, mais pas le serveur, ou si le client n'a pas de fichier keytab ou les commettants du service requis, le client utilise AUTH_SYS et l'UID 0 pour la gestion des baux. Utiliser un port source non privilegie Le client NFS communique normalement avec les serveurs NFS par des sockets de reseau. A chaque extremite d'un socket est associee une valeur de port qui est un simple nombre entre 1 et 65 535 qui permettent de distinguer ces terminaisons d'acces de socket pour la meme adresse IP. Un socket est identifie de maniere unique par un n-uplet comprenant le protocole de transport (TCP ou UDP) et les valeurs de port et d'adresse IP de chaque terminaison d'acces. Le client NFS peut choisir n'importe quelle valeur de port source pour ses sockets, mais il choisit en general un port privilegie (c'est-a-dire avec une valeur inferieure a 1024). Seul un processus tournant avec des droits du superutilisateur peut creer un socket a partir d'un port source privilegie. La plage des ports source privilegies pouvant etre choisis est definie par une paire de << sysctl >>s pour eviter l'utilisation d'un port bien connu, tel celui de SSH. Cela signifie que le nombre de ports source disponibles pour le client NFS, et donc le nombre de connexions de socket disponibles a un moment donne, est en pratique limite a quelques centaines. Comme decrit plus haut, le schema d'authentification NFS traditionnel par defaut (connu sous le nom d'AUTH_SYS) repose sur l'envoi d'UID et de GID locaux pour identifier les utilisateurs a l'origine de requetes. Un serveur NFS suppose que si une connexion provient d'un port privilegie, les numeros d'UID et de GID des requetes NFS sur cette connexion ont deja ete verifies par le noyau du client ou toute autre autorite locale. Ce systeme est facile a usurper, mais sur un reseau physique securise entre hotes verifies, c'est parfaitement adapte. En gros, un socket est utilise pour chaque point de montage NFS. Si un client peut aussi utiliser un port source non privilegie, le nombre de sockets autorises (et donc le nombre maximal de points de montage simultanes) sera beaucoup plus important. Utiliser un port source non privilegie peut quelque peu compromettre la securite du serveur, car n'importe quel utilisateur d'un point de montage AUTH_SYS peut maintenant se faire passer pour un autre comme source de la requete. C'est pourquoi les serveurs NFS ne le prennent pas en charge par defaut. En regle generale, ils l'autorisent explicitement a l'aide d'une option d'exportation. Pour garder un bon niveau de securite tout en permettant un maximum de points de montage, il est preferable de n'autoriser les connexions clientes sur un port non privilegie que si le serveur et le client utilisent tous deux une authentification forte, comme celle fournie par Kerberos. Montage a travers un pare-feu Un pare-feu peut exister entre un client NFS et le serveur, mais le client ou le serveur peuvent bloquer certains de leurs propres ports grace a des regles de filtrage d'IP. Il est toujours possible de monter un serveur NFS a travers un pare-feu, bien que les mecanismes de decouverte automatique des terminaisons d'acces (endpoint) de la commande mount(8) peuvent ne pas fonctionner. Il faudra alors fournir les details specifiques a ces terminaisons d'acces grace aux options de montage. Les serveurs NFS lancent habituellement un demon portmapper ou rpcbind pour annoncer aux clients les terminaisons d'acces aux services. Les clients se servent du demon rpcbind pour determiner : le port reseau utilise par chaque service base sur les RPC, les protocoles de transport pris en charge par chaque service base sur les RPC. Le demon rpcbind utilise un port bien connu (111) afin d'aider les clients a trouver la terminaison d'acces a un service. Bien que NFS utilise souvent un numero de port standard (2049), des services auxiliaires tels que NLM peuvent choisir aleatoirement des numeros de port inutilises. Les configurations habituelles des pare-feu bloquent le port bien connu de rpcbind. En l'absence du service rpcbind, l'administrateur du serveur definit un numero de port pour les services lies a NFS afin que le pare-feu puisse permettre l'acces aux ports des services specifiques NFS. Les administrateurs des clients pourront alors indiquer le numero du port du service mountd grace a l'option mountport de la commande mount(8). Il peut etre necessaire d'imposer l'utilisation de TCP ou d'UDP si le pare-feu bloque l'un de ces transports. Desactiver le traitement des ACL (Access Control List). Solaris permet aux clients NFS version 3 l'acces direct aux ACL (Access Control Lists) POSIX stockees dans son systeme de fichiers local. Ce protocole auxiliaire proprietaire, connu sous le nom de NFSACL, offre un controle d'acces plus riche que le mode par bits. Linux implemente ce protocole dans un but de compatibilite avec l'implementation NFS de Solaris. Cependant, le protocole NFSACL n'est jamais devenu une partie standard de la specification NFS version 3. La specification de NFS version 4 impose une nouvelle version des Access Control Lists qui sont semantiquement plus riches que les ACL POSIX. Les ACL de NFS version 4 ne sont pas totalement compatibles avec les ACL POSIX. De ce fait, des traductions entre les deux sont obligatoires dans un environnement qui melange les ACL POSIX et NFS version 4. OPTION DE REMONTAGE Les options de montage generique comme rw et sync peuvent etre modifiees par les points de montage NFS en utilisant l'option remount. Consulter mount(8) pour plus d'informations sur les options generiques de montage. Sauf quelques exceptions, les options specifiques a NFS ne peuvent pas etre modifiees pendant un remontage. Par exemple, le transport sous-jacent ou la version NFS ne peuvent pas etre changes par un remontage. Effectuer un remontage sur un systeme de fichiers NFS monte avec l'option noac peut avoir des consequences inattendues. L'option noac est une combinaison de l'option generique sync et de l'option specifique NFS actimeo=0. Demontage apres remontage Pour les points de montage qui utilisent NFS versions 2 ou 3, la sous-commande de demontage NFS depend de la connaissance de l'ensemble initial des options de montage utilisees pour effectuer l'operation MNT. Ces options sont stockees sur le disque par la sous-commande de montage NFS, et peuvent etre effacees par un remontage. Afin de s'assurer que les options de montage enregistrees ne sont pas effacees lors d'un remontage, il faut specifier au remontage soit le repertoire de montage local, soit le serveur hote et le chemin d'exportation, mais pas les deux. Par exemple, mount -o remount,ro /mnt fusionne l'option de montage ro avec les options de montage deja enregistrees sur le disque pour le serveur NFS monte dans /mnt. FICHIERS /etc/fstab Table des systemes de fichiers /etc/nfsmount.conf Fichier de configuration pour les montages NFS NOTES Le client Linux NFS anterieur a 2.4.7 ne gerait pas NFS sur TCP. Le client Linux NFS anterieur a 2.4.20 utilisait une heuristique pour savoir si les donnees en cache d'un fichier etaient toujours valables plutot que d'utiliser la methode standard de coherence de cache close-to-open decrite ci-dessus. Depuis la version 2.4.22, le client Linux NFS utilise une estimation RTT (Round Trip Time) de type Van Jacobsen pour definir les delais de depassement de temps lorsqu'il utilise NFS sur UDP. Le client Linux NFS anterieur a 2.6.0 ne gerait pas NFS version 4. Le client Linux NFS anterieur a 2.6.8 n'utilisait les lectures et ecritures synchrones que lorsque les reglages de rsize et wsize etaient inferieurs a la taille des pages du systeme. La prise en charge d'un client Linux pour les versions de protocole depend de l'activation des options CONFIG_NFS_V2, CONFIG_NFS_V3, CONFIG_NFS_V4, CONFIG_NFS_V4_1 et CONFIG_NFS_V4_2 lors de la construction du noyau. VOIR AUSSI fstab(5), mount(8), umount(8), mount.nfs(5), umount.nfs(5), exports(5), nfsmount.conf(5), netconfig(5), ipv6(7), nfsd(8), sm-notify(8), rpc.statd(8), rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1) RFC 768 concernant la specification UDP. RFC 793 concernant la specification TCP. RFC 1813 concernant la specification de NFS version 3. RFC 1832 concernant la specification XDR. RFC 1833 concernant la specification RPC bind. RFC 2203 concernant la specification du protocole de l'API GSS RPCSEC. RFC 7530 concernant la specification de NFS version 4.0 RFC 5661 concernant la specification de NFS version 4.1. RFC 7862 concernant la specification de NFS version 4.2. TRADUCTION La traduction francaise de cette page de manuel a ete creee par Valery Perrin , Sylvain Cherrier , Thomas Huriaux , Dominique Simen , Nicolas Sauzede , Romain Doumenc , David Prevot , Denis Mugnier , Cedric Boutillier et Jean-Paul Guillonneau Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . 9 octobre 2012 NFS(5)