Provided by:
manpages-fr-extra_20070512_all 
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 permet‐
tant 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’écrit‐
ure 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 (antislash) 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 le nombre d’octets
demandé.
Le descripteur de fichier («lehandle ») 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’iden‐
tifiant du système de fichiers est stocké dans les descripteurs
de fichier («lehandle »), 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 con‐
tenus 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 commen‐
taire (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 con‐
tenant 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 (kernel header files) pour savoir à quoi
correspond chaque nombre.
rpc.nfsd(8), exports(5), nfsstat(8), mountd(8), exportfs(8).
AUTEUR
NeilBrown
TRADUCTION
Cette page de manuel a été traduite et est maintenue par Sylvain Cher‐
rier <sylvain DOT cherrier AT free DOT fr> et les membres de la liste
<debian-l10n-french AT lists DOT debian DOT org> depuis 2006. Veuillez
signaler toute erreur de traduction par un rapport de bogue sur le
paquet manpages-fr-extra.
3 juillet 2003 nfsd(7)