table of contents
NFSD(7) | Manuel de l'administrateur Linux | NFSD(7) |
NOM¶
nfsd - Système de fichiers spécial permettant le contrôle du serveur NFS de Linux
SYNOPSIS¶
mount -t nfsd nfsd /proc/fs/nfsd
DESCRIPTION¶
Le système de fichiers nfsd est un système de fichiers spécial permettant de dialoguer avec le serveur NFS de Linux. Ce système de fichiers ne contient qu'un seul répertoire avec un certain nombre de fichiers. Ces fichiers sont en fait des passerelles vers le serveur NFS. L'écriture dans ces fichiers affectera le comportement du serveur. La lecture du contenu de ces fichiers fournira des informations à propos du serveur.
Ce système de fichiers n'est disponible que dans les versions 2.6 et suivantes du noyau Linux (ainsi que dans les dernières versions de développement 2.5 amenant vers la série 2.6). Cette page de manuel ne concerne pas les noyaux 2.4 et précédents.
Comme pour ce système de fichiers, il existe un ensemble de fichiers dans le système de fichiers procfs (habituellement monté dans /proc) qui permettent le contrôle du serveur NFS. Cette page de manuel décrit tous ces fichiers.
Les programmes exportfs et mountd (fournis dans le paquet nfs-utils) s'attendent à trouver ce système de fichiers monté dans /proc/fs/nfsd ou /proc/fs/nfs. Si ce n'est pas le cas, ces programmes se rabattront sur les fonctionnalités du noyau 2.4. Cela implique un accès au serveur NFS via un appel système. Cet appel système devrait disparaître des noyaux qui succéderont à la série 2.6.
DÉTAILS¶
Les trois fichiers présents dans le système de fichiers nfsd sont :
- exports
- Ce fichier contient la liste des systèmes de fichiers qui sont
actuellement partagés, les clients vers lesquels ils le sont, ainsi
que la liste des options de partage pour chacune des paires
client/système de fichiers. Cela ressemble au contenu du fichier
/proc/fs/nfs/exports du noyau 2.4. La différence,
c'est qu'un client ne correspond pas nécessairement à une
seule et unique machine. Il peut s'agir d'un nombre important
d'hôtes qui seront traités à l'identique.
Chaque ligne de ce fichier contient un chemin, le nom d'un client et un nombre d'options entre parenthèses. Tout caractère espace, tabulation, retour à la ligne ou barre oblique inverse présent dans le nom d'un chemin ou d'un client sera remplacé par un caractère barre oblique inverse suivi du code ASCII de ce caractère, exprimé en octal.
- threads
- Ce fichier contient le nombre de processus légers (thread) de nfsd actuellement en cours d'exécution. La lecture du fichier affichera le nombre de processus légers. Écrire un nombre décimal en ASCII modifiera le nombre de processus légers (à la hausse ou à la baisse) afin d'atteindre la valeur demandée.
- filehandle
- C'est un fichier un peu inhabituel, puisque ce qu'on y lit dépend
de ce que l'on vient juste d'y écrire. Il offre une interface
transactionnelle afin qu'un programme puisse ouvrir ce fichier, y
écrire une requête, et y lire la réponse. Si deux
programmes différents ouvrent, écrivent, et lisent ce
fichier au même moment, leurs requêtes ne se
mélangeront pas.
Les requêtes écrites dans filehandle devront être de la forme un nom de client, un nom de chemin et un nombre d'octets. Un retour à la ligne terminera la requête, les champs seront séparés par une espace, et tout caractère spécial sera protégé et écrit en octal.
Grâce à cette écriture, le programme pourra accéder à un descripteur de fichier (« filehandle ») pour ce chemin, tel qu'il est partagé pour ce client. La taille de ce descripteur de fichier (« filehandle ») sera au plus du nombre d'octets demandé.
Le descripteur de fichier (« filehandle ») sera représenté en hexadécimal, et préfixé par « \x ».
Le répertoire /proc/net/rpc du système de fichiers procfs contient un certain nombre de fichiers et de répertoires. Ces fichiers contiennent des statistiques qui peuvent être affichées grâce au programme nfsstat. Les répertoires contiennent des informations sur les différents caches que le serveur NFS utilise pour assurer le suivi des permissions d'accès dont disposent les différents clients sur les différents systèmes de fichiers. Ces caches sont :
- auth.domain
- Ce cache fait la correspondance entre le nom d'un client (ou d'un domaine) et une structure de données interne. Le seul accès possible permet de vider le cache.
- auth.unix.ip
- Ce cache contient la correspondance entre les adresses IP et les noms du domaine d'authentification auxquels ces adresses IP sont rattachées.
- nfsd.export
- Ce cache contient la correspondance entre les répertoires, les domaines et les options de partage.
- nfsd.fh
- Ce cache contient la correspondance entre les domaines, les identifiants du système de fichiers et les répertoires. L'identifiant du système de fichiers est stocké dans les descripteurs de fichier (« filehandle »), et est composé d'un nombre indiquant le type d'identifiant, ainsi qu'un nombre d'octets en hexadécimal indiquant le contenu de cet identifiant.
Chaque répertoire représentant un cache peut contenir de 1 à 3 fichiers. Ce sont :
- flush
- Quand un nombre de secondes depuis l'Époque Unix (1 janvier 1970) est écrit dans ce fichier, toutes les mises à jour de contenus postérieures à cette date seront invalidées, et vidées du cache. Écrire 1 dans ce fichier videra tout. Ce fichier est le seul qui est toujours présent.
- content
- Ce fichier, s'il est présent, contient une représentation littérale de tous les contenus du cache, un par ligne. Si un contenu est toujours dans le cache (parce qu'il est actuellement en cours d'utilisation), mais qu'il est dépassé, ou invalide pour une raison quelconque, il sera affiché en tant que commentaire (avec un dièse en début de ligne).
- channel
- Ce fichier, s'il existe, sert de canal de communication entre le serveur
NFS en mode noyau et le programme en espace utilisateur.
Quand le noyau a besoin d'informations qui ne sont pas dans le cache, il écrit une ligne dans le fichier channel qui fournit une clé pour cette information. Un programme en mode utilisateur pourra la lire, trouver une réponse, puis écrire une ligne contenant la clé, une date d'expiration, et le contenu de la réponse. Par exemple, le noyau pourrait écrire nfsd 127.0.0.1
dans le fichier auth.unix.ip/content. Le programme en espace utilisateur pourra alors écrire nfsd 127.0.0.1 1057206953 localhost
pour dire que 127.0.0.1 doit correspondre à « localhost », à ce moment précis.Si le programme utilise select(2) ou poll(2) pour découvrir s'il peut lire le contenu de channel, il n'obtiendra jamais la fin de fichier. Si toutes les requêtes ont été résolues, il sera bloqué jusqu'à ce qu'une autre requête arrive.
Dans le système de fichiers /proc, il y 4 fichiers
qui peuvent être utilisés pour tracer un peu plus nfsd et les
autres programmes associés. Il s'agit de :
/proc/sys/sunrpc/nfs_debug
/proc/sys/sunrpc/nfsd_debug
/proc/sys/sunrpc/nlm_debug
/proc/sys/sunrpc/rpc_debug
Ils contrôlent respectivement le traçage de client NFS, du
serveur NFS, du gestionnaire de verrouillage réseau (lockd) et de la
couche RPC sous-jacente. Des nombres décimaux peuvent être lus
ou écrits dans ces fichiers. Chaque nombre représente un
schéma de bits dans lesquels ces bits définissent certaines
classes de traçage à activer. Consultez les fichiers
d'en-têtes du noyau pour savoir à quoi correspond chaque
nombre.
AUTEUR¶
Neil Brown
VOIR AUSSI¶
TRADUCTION¶
Ce document est une traduction réalisée par Sylvain Cherrier <sylvain DOT cherrier AT free DOT fr> le 3 juillet 2006 et révisée le 25 avril 2008.
L'équipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. La version anglaise la plus à jour de ce document est toujours consultable via la commande : « LANG=C man 7 nfsd ». N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.
3 juillet 2003 | nfs-utils-1.1.1 |