nfs - Format de fstab et options pour les systèmes de fichiers
nfs
/etc/fstab
NFS is an Internet Standard protocol created by Sun Microsystems in 1984. NFS
was developed to allow file sharing between systems residing on a local area
network. Depending on kernel configuration, the Linux NFS client may support
NFS versions 3, 4.0, 4.1, or 4.2.
La commande
mount(8) lie un système de fichiers au point de
montage donné dans l'espace de noms hiérarchisé du
système. Le fichier
/etc/fstab décrit la façon
dont
mount(8) doit recréer la hiérarchie de l'espace de
noms du système de fichiers à partir de systèmes de
fichiers indépendants (dont ceux partagés par des serveurs NFS).
Chacune des lignes du fichier
/etc/fstab décrit un unique
système de fichiers, son point de montage, et un ensemble d'options par
défaut pour ce point de montage.
Dans le cas des montages de systèmes de fichiers NFS, une ligne dans le
fichier
/etc/fstab indique le nom du serveur, le chemin du
répertoire partagé à monter, le répertoire local
qui sera le point de montage, le type de système de fichiers à
monter et la liste des options de montage qui indique la façon dont le
système de fichiers sera monté et quel sera le comportement du
client NFS lorsqu'il accédera aux fichiers du point de montage. Le
cinquième et le sixième champs de chaque ligne ne sont pas
utilisés par NFS, et par conséquent contiennent par convention
la valeur zéro. Par exemple :
serv:chemin /pt_montage type_fs option,option,... 0 0
Le nom du serveur et le chemin de partage sont séparés par un deux
points, tandis que les options de montage sont séparées par des
virgules. Les champs restants sont séparés par des espaces ou
des tabulations.
Le nom du serveur peut être un nom d'hôte non qualifié, un
nom de domaine pleinement qualifié (« fully qualified
domain name »), une adresse IPv4, ou une adresse IPv6
entourée par des crochets. Les adresses IPv6 de liens locaux ou de
sites locaux doivent être accompagnées d'un identifiant
d'interface. Référez-vous à
ipv6(7) pour des
détails quant à l'écriture des adresses IPv6 brutes.
Le champ
fstype contient « nfs ». La valeur
« nfs4 » est obsolète.
Consultez
mount(8) pour la description des options de montage
génériques disponibles pour tous les systèmes de
fichiers. Si vous n'avez pas besoin d'indiquer d'options de montage
particulières, utilisez l'option générique
defaults dans
/etc/fstab.
Les options suivantes peuvent être utilisées avec n'importe quelle
version de NFS.
-
nfsvers=n
- The NFS protocol version number used to contact the
server's NFS service. If the server does not support the requested
version, the mount request fails. If this option is not specified, the
client tries version 4.2 first, then negotiates down until it finds a
version supported by the server.
-
vers=n
- This option is an alternative to the nfsvers option.
It is included for compatibility with other operating systems
-
soft / hard
- Définir le comportement de
récupération du client NFS lorsqu'une requête NFS ne
répond pas (« time out »). Si aucune
option n'est indiquée (ou si c'est l'option hard qui a
été choisie), les requêtes NFS sont retentées
indéfiniment. Si par contre l'option soft a
été choisie, le client NFS lèvera un échec
après l'envoi de retrans retransmissions, entraînant
alors le retour d'une erreur à l'application appelante.
-
NB : Un délai expiré
« soft » peut provoquer dans certains cas des
erreurs de données non signalées. C'est pourquoi l'option
soft doit être utilisée uniquement si la
réactivité du client est plus importante que
l'intégrité des données. L'utilisation de NFS avec
TCP ou l'augmentation de la valeur de l'option retrans peut
diminuer les risques liés à l'utilisation de l'option
soft.
-
softreval / nosoftreval
- In cases where the NFS server is down, it may be useful to
allow the NFS client to continue to serve up paths and attributes from
cache after retrans attempts to revalidate that cache have timed
out. This may, for instance, be helpful when trying to unmount a
filesystem tree from a server that is permanently down.
- It is possible to combine softreval with the
soft mount option, in which case operations that cannot be served
up from cache will time out and return an error after retrans
attempts. The combination with the default hard mount option
implies those uncached operations will continue to retry until a response
is received from the server.
- Note: the default mount option is nosoftreval which
disallows fallback to cache when revalidation fails, and instead follows
the behavior dictated by the hard or soft mount option.
-
intr / nointr
- This option is provided for backward compatibility. It is
ignored after kernel 2.6.25.
-
timeo=n
- Le temps en dixièmes de seconde où le client
NFS attend une réponse avant qu'il réessaie une
requête NFS.
- Pour NFS sur TCP, la valeur timeo est de 600
par défaut (60 secondes). Le client NFS effectue une
progression linéaire : après chaque retransmission la
temporisation est augmentée de timeo jusqu'au maximum de
600 secondes.
- Cependant, dans le cas de NFS sur UDP, le client utilise un
algorithme évolutif pour estimer la valeur appropriée de
dépassement de temps (« timeout ») pour
les types de requêtes fréquemment utilisées (les
requêtes READ et WRITE par exemple), mais utilise le réglage
timeo pour les requêtes moins courantes (comme FSINFO). Si
l'option timeo n'est pas définie, les types de
requêtes moins courantes sont ré-émises après
1,1 secondes. Après chaque ré-émission, le
client NFS double la valeur de dépassement de temps pour cette
requête, jusqu'à atteindre un maximum de
60 secondes.
-
retrans=n
- The number of times the NFS client retries a request before
it attempts further recovery action. If the retrans option is not
specified, the NFS client tries each UDP request three times and each TCP
request twice.
- Le client NFS génère un message
« le serveur ne répond pas »
après retrans tentatives, puis enclenche la
récupération (qui dépend de l'activation de l'option
hard de mount).
-
rsize=n
- Nombre maximal d'octets pour chaque requête
réseau en LECTURE que peut recevoir le client NFS lorsqu'il lit les
données d'un fichier sur le serveur NFS. La taille réelle de
la charge utile de données pour chaque requête NFS en
LECTURE est plus petite ou égale au réglage rsize. La
plus grande charge utile gérée par le client NFS Linux est
de 1 048 576 octets (un méga-octet).
- La valeur de rsize est un entier positif multiple de
1024. Les valeurs de rsize inférieures à 1024 sont
remplacées par 4096, et celles supérieures à
1 048 576 sont remplacées par
1 048 576. Si la valeur indiquée est bien dans la
plage gérée, mais qu'elle n'est pas un multiple de 1024,
elle sera arrondie au multiple de 1024 inférieur le plus
proche.
- Si la valeur de rsize n'est pas définie, ou
si la valeur de rsize dépasse le maximum qu'à la fois
le client et le serveur peuvent gérer, le client et le serveur
négocient la plus grande valeur de rsize qu'ils peuvent
gérer ensemble.
- L'option rsize de mount telle qu'elle a
été définie sur la ligne de commande lors du
mount(8) apparaît dans le fichier /etc/mtab. D'autre
part, la valeur réelle de rsize négociée entre
le client et le serveur est indiquée dans le fichier
/proc/mounts.
-
wsize=n
- Nombre maximal d'octets par requête
d'ÉCRITURE réseau que le client NFS peut envoyer quand il
écrit des données dans un fichier sur un serveur NFS. La
taille réelle de la charge utile de données pour chaque
requête NFS en ÉCRITURE est plus petite ou égale au
réglage wsize. La plus grande charge utile
gérée par le client NFS Linux est de
1 048 576 octets (un méga-octet).
- Comme pour rsize, la valeur de wsize est un
entier positif multiple de 1024. Les valeurs de wsize
inférieures à 1024 sont remplacées par 4096, et
celles supérieures à 1 048 576 par
1 048 576. Si la valeur définie est bien dans
l'étendue valide mais qu'elle n'est pas multiple de 1024, elle est
arrondie au multiple de 1024 inférieur le plus proche.
- Si la valeur de wsize n'est pas définie, ou
si la valeur wsize indiquée est supérieure au maximum
que soit le client soit le serveur peut gérer, le client et le
serveur négocient la plus grande valeur de wsize qu'ils
peuvent tous les deux gérer.
- L'option wsize de mount telle qu'elle a
été indiquée sur la ligne de commande du
mount(8) apparaît dans le fichier /etc/mtab. D'autre
part, la valeur réelle de wsize négociée par
le client et le serveur est indiquée dans le fichier
/proc/mounts.
-
ac / noac
- Définir si le client peut mémoriser (cache)
les attributs des fichiers. Si aucune option n'est indiquée (ou si
c'est ac qui est choisi), le client mémorise les attributs
des fichiers.
- Afin d'améliorer les performances, les clients NFS
mémorisent (mettent en cache) les attributs des fichiers. Toutes
les quelques secondes, un client NFS vérifie les attributs de
chaque fichier de la version du serveur afin de se mettre à jour.
Les modifications qui interviennent pendant ces petits intervalles restent
inaperçues tant que le client n'a pas relancé sa
vérification sur le serveur. L'option noac empêche la
mémorisation des attributs de fichiers par le client, ce qui permet
aux applications de détecter plus rapidement les modifications des
fichiers sur le serveur.
- En plus d'empêcher le client de mémoriser les
attributs des fichiers, l'option noac force l'écriture
synchronisée pour les applications afin que les modifications sur
un fichier soient immédiatement visibles sur le serveur. De cette
façon, les autres clients peuvent rapidement détecter les
nouvelles écritures lors de la vérification des attributs du
fichier.
- L'usage de l'option noac offre une plus grande
cohérence du cache aux clients NFS qui accèdent aux
mêmes fichiers, mais au prix d'une pénalisation
significative des performances. C'est pour cette raison qu'une utilisation
judicieuse des verrouillages (« locking ») de
fichiers est préférable. La section COHÉRENCE DES
DONNÉES ET DES MÉTADONNÉES contient une
présentation détaillée de ces approches.
-
acregmin=n
- The minimum time (in seconds) that the NFS client caches
attributes of a regular file before it requests fresh attribute
information from a server. If this option is not specified, the NFS client
uses a 3-second minimum. See the DATA AND METADATA COHERENCE section for a
full discussion of attribute caching.
-
acregmax=n
- The maximum time (in seconds) that the NFS client caches
attributes of a regular file before it requests fresh attribute
information from a server. If this option is not specified, the NFS client
uses a 60-second maximum. See the DATA AND METADATA COHERENCE section for
a full discussion of attribute caching.
-
acdirmin=n
- The minimum time (in seconds) that the NFS client caches
attributes of a directory before it requests fresh attribute information
from a server. If this option is not specified, the NFS client uses a
30-second minimum. See the DATA AND METADATA COHERENCE section for a full
discussion of attribute caching.
-
acdirmax=n
- The maximum time (in seconds) that the NFS client caches
attributes of a directory before it requests fresh attribute information
from a server. If this option is not specified, the NFS client uses a
60-second maximum. See the DATA AND METADATA COHERENCE section for a full
discussion of attribute caching.
-
actimeo=n
- L'utilisation de actimeo configure toutes les
durées acregmin, acregmax, acdirmin et
bacdirmax à la même valeur. Si cette option n'est pas
définie, le client utilisera les valeurs par défaut de
chacune des options, telles que décrites ci-dessus.
-
bg / fg
- Déterminer le comportement de la commande
mount(8) dans le cas d'un échec d'une tentative de montage
d'un partage. L'option fg entraîne l'arrêt de
mount(8) avec un statut d'erreur si la moindre partie de la
requête de montage dépasse le temps alloué ou
échoue d'une quelconque autre manière. C'est ce que l'on
appelle le montage en « premier plan
(foreground) », et c'est le comportement par défaut
si ni fg ni bg n'est indiqué.
- Si l'option bg est indiquée, un
dépassement du temps alloué (timeout) ou un échec
entraînera la création d'un fils (fork) qui continuera
à essayer de monter le partage. Le père s'interrompt
immédiatement en renvoyant un code de sortie à zéro.
C'est ce que l'on appelle le montage en
« arrière-plan (background) ».
- Si le répertoire servant de point de montage local
n'existe pas, la commande mount(8) se comporte comme si la
requête était restée sans réponse (timeout).
Cela permet aux montages NFS imbriqués définis dans
/etc/fstab de s'exécuter dans n'importe quel ordre lors de
l'initialisation du système, même si certains serveurs NFS
ne sont pas encore disponibles. On peut aussi gérer ces
problèmes grâce à un auto-monteur (consultez
automount(8) pour plus de détails).
-
nconnect=n
- When using a connection oriented protocol such as TCP, it
may sometimes be advantageous to set up multiple connections between the
client and server. For instance, if your clients and/or servers are
equipped with multiple network interface cards (NICs), using multiple
connections to spread the load may improve overall performance. In such
cases, the nconnect option allows the user to specify the number of
connections that should be established between the client and server up to
a limit of 16.
- Note that the nconnect option may also be used by
some pNFS drivers to decide how many connections to set up to the data
servers.
-
max_connect=n
- While nconnect option sets a limit on the number of
connections that can be established to a given server IP,
max_connect option allows the user to specify maximum number of
connections to different server IPs that belong to the same NFSv4.1+
server (session trunkable connections) up to a limit of 16. When client
discovers that it established a client ID to an already existing server,
instead of dropping the newly created network transport, the client will
add this new connection to the list of available transports for that RPC
client.
-
rdirplus / nordirplus
- Indiquer s'il faut utiliser les requêtes READDIRPLUS
de NFS version 3 ou 4. Si cette option n'est pas définie, le
client NFS utilisera les requêtes READDIRPLUS sur les montages en
NFS version 3 ou 4 pour la lecture des petits répertoires.
Certaines applications sont plus efficaces si le client n'utilise que des
requêtes READDIR pour tous les répertoires.
-
retry=n
- Durée, en minute, pendant laquelle le montage NFS
sera tenté par la commande mount(8), en arrière-plan
ou au premier plan, avant d'abandonner. Si l'option n'est pas
définie, la valeur par défaut pour le premier plan est de
2 minutes, et celle pour l'arrière-plan est
10 000 minutes, soit environ une semaine, à
80 minutes près. La commande mount(8)
s'arrêtera dès le premier échec si on lui passe la
valeur 0.
- Note that this only affects how many retries are made and
doesn't affect the delay caused by each retry. For UDP each retry takes
the time determined by the timeo and retrans options, which
by default will be about 7 seconds. For TCP the default is 3 minutes, but
system TCP connection timeouts will sometimes limit the timeout of each
retransmission to around 2 minutes.
-
sec=flavors
- A colon-separated list of one or more security flavors to
use for accessing files on the mounted export. If the server does not
support any of these flavors, the mount operation fails. If sec= is
not specified, the client attempts to find a security flavor that both the
client and the server supports. Valid flavors are none,
sys, krb5, krb5i, and krb5p. Refer to the
SECURITY CONSIDERATIONS section for details.
-
sharecache / nosharecache
- Déterminer comment le client partage ses caches de
données et d'attributs de fichiers lorsqu'un même partage
est monté plus d'une fois en même temps. L'utilisation d'un
seul cache réduit les besoins en mémoire sur le client et
présente aux applications un contenu identique lorsque l'on
accède au même fichier partagé par différents
points de montage.
- Si aucune des options n'est indiquée, ou si l'option
sharecache est demandée, un seul cache est utilisé
pour tous les points de montage qui accèdent au même
partage. Si l'option nosharecache est indiquée, ce point de
montage utilise son propre cache. Notez que lorsque les caches des
données et des attributs sont partagés, les options de
montage du premier point de montage s'appliquent pour les futurs montages
de ce même partage, tant que celui-ci est monté.
- En ce qui concerne le noyau 2.6.18, le comportement
défini par nosharecache est le comportement traditionnel
normal. Ceci est considéré comme dangereux pour les
données puisque de multiples copies mémorisées du
même fichier sur le même client peuvent se
désynchroniser suite à une mise à jour locale d'une
des copies.
-
resvport / noresvport
- Indiquer si le client NFS doit utiliser un port source
privilégié quand il communique avec un serveur NFS pour ce
point de montage. Si cette option n'est pas précisée, ou si
l'option resvport est précisée, le client NFS utilise
un port source privilégié. Si l'option noresvport est
activée, le client NFS utilise un port source non
privilégié. Cette option est permise par les noyaux 2.6.28
et suivants.
- Utiliser un port source non privilégié permet
d'augmenter le nombre maximal de points de montage permis par client, mais
les serveurs NFS doivent être configurés pour permettre la
connexion de clients par des ports source non
privilégiés.
- Veuillez consulter la section CONSIDÉRATIONS DE
SÉCURITÉ pour d'importantes précisions.
-
lookupcache=mode
- Préciser comment le noyau s'occupe du cache des
entrées de répertoire pour un point de montage donné.
mode peut être 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
résultats des requêtes NFS LOOKUP. Si le répertoire
indiqué existe sur le serveur, le résultat renvoyé
est positif (« positive »), sinon c'est
négatif (« negative »).
- Si cette option n'est pas précisée, ou si
all est précisé, le client suppose que les deux types
d'entrées ( positif ou négatif) du cache de
répertoire sont valables jusqu'à ce que le cache de leur
répertoire parent expire.
- Si pos ou positive est précisé,
le client suppose que les entrées positives sont valables
jusqu'à ce que le cache de leur répertoire parent expire,
mais valide les entrées négatives avant qu'une application
les utilise.
- Si none est précisé, le client valide
à nouveau les deux types d'entrées de cache de
répertoire avant qu'une application puisse les utiliser. Cela
permet une détection rapide des fichiers qui ont été
créés ou supprimés par d'autres clients, mais peut
avoir des répercussions sur ces applications et les performances du
serveur.
- La partie COHÉRENCE DES DONNÉES ET DES
MÉTADONNÉES contient un propos détaillé
sur ces échanges.
-
fsc / nofsc
- Enable/Disables the cache of (read-only) data pages to the
local disk using the FS-Cache facility. See cachefilesd(8) and
<kernel_source>/Documentation/filesystems/caching for detail on how
to configure the FS-Cache facility. Default value is nofsc.
- sloppy
- The sloppy option is an alternative to specifying
mount.nfs -s option.
Utilisez ces options ainsi que les options de la sous-section
précédente uniquement pour les systèmes de fichiers de
type NFS version 2 et 3.
-
proto=idreseau
- The netid determines the transport that is used to
communicate with the NFS server. Available options are udp,
udp6, tcp, tcp6, rdma, and rdma6. Those
which end in 6 use IPv6 addresses and are only available if support
for TI-RPC is built in. Others use IPv4 addresses.
- Chaque protocole de transport utilise différents
réglages de retransmission et de timeo. Merci de vous
référer à la description de ces deux options de
montage
- En plus de contrôler la façon dont le client
NFS transmet les requêtes au serveur, cette option de mount
gère aussi la façon dont la commande mount(8)
communique avec les services rpcbind et mountd du serveur. Indiquer un id
réseau qui utilise TCP entraîne l'utilisation de TCP par
tout le trafic passant par la commande mount(8) ou le client NFS.
Réciproquement, indiquer UDP entraîne l'utilisation d'UDP
par tout le trafic.
- avant d'utiliser NFS sur UDP, consultez la section
MÉTHODES DE TRANSPORT.
- Si l'option proto de mount n'est pas
définie, la commande mount(8) découvrira quels
protocoles sont acceptés par le serveur et choisira un transport
approprié pour chacun des services. Consultez la section
MÉTHODES DE TRANSPORT pour plus de détails.
- udp
- L'option udp est une variante pour proto=udp,
compatible avec d'autres systèmes d'exploitation.
- avant d'utiliser NFS sur UDP, consultez la section
MÉTHODES DE TRANSPORT.
- tcp
- L'option tcp est une variante pour proto=tcp,
compatible avec d'autres systèmes d'exploitation.
- rdma
- L'option rdma est une variante pour
proto=rdma.
-
port=n
- Valeur numérique du port du service NFS sur le
serveur. Si le service NFS du serveur n'est pas accessible sur le port
indiqué, la requête de montage échoue.
- Si cette option n'est pas définie, ou si le port
indiqué est 0, le client NFS utilise le numéro du port du
service NFS publié par le service rpcbind du serveur. La
requête de montage échoue si le service rpcbind du serveur
n'est pas accessible, si le service NFS du serveur n'est pas
enregistré dans son service rpcbind, ou si le service NFS du
serveur n'est pas accessible sur le port publié.
-
mountport=n
- Valeur numérique du port de mountd sur le serveur.
Si le service mountd du serveur n'est pas présent sur le port
indiqué, la requête de montage échoue.
- Si cette option n'est pas définie, ou si le port
indiqué est 0, la commande mount(8) utilise le numéro
du port du service mountd publié par le service rpcbind du serveur.
La requête de montage échoue si le service rpcbind du
serveur n'est pas accessible, si le service mountd du serveur n'est pas
enregistré dans son service rpcbind, ou si le service mountd du
serveur n'est pas accessible sur le port publié.
- Cette option peut être utilisée pour les
montages sur un serveur NFS à travers un pare-feu qui bloque le
protocole rpcbind.
-
mountproto=idreseau
- Le transport utilisé par le client NFS pour
transmettre ses requêtes au service mountd d'un serveur NFS quand
il lance cette requête de montage, puis quand il démontera
ensuite ce montage.
-
idreseau peut valoir udp ou tcp qui
utilisent des adresses IPv4, ou bien, si TI-RPC est intégré
dans la commande mount.nfs, udp6 ou tcp6, qui
utilisent des adresses IPv6.
- Cette option peut être utilisée pour monter
un serveur NFS à travers un pare-feu qui bloque des transferts
spécifiques. Utilisé avec l'option proto,
différents modes de transfert peuvent être choisis pour les
requêtes vers mountd et NFS. Si le serveur ne propose pas de
service pour le mode indiqué, la requête de montage
échoue.
- Veuillez consulter la section MÉTHODES DE
TRANSPORT pour plus de renseignements sur la manière dont
l'option de montage mountproto interagit avec l'option
proto.
-
mounthost=nom
- Le nom d'hôte de la machine qui exécute le
mountd. Si cette option n'est pas définie, la commande
mount(8) considère que le service mountd est assuré
par la machine qui offre le service NFS.
-
mountvers=n
- Numéro de version des RPC utilisé pour
contacter le mountd du serveur. Si cette option n'est pas définie,
le client utilise un numéro de version approprié à la
version du NFS contacté. Cette option est utile quand de nombreux
services NFS sont offerts par un seul et même serveur.
-
namlen=n
- La taille maximale d'un composant du nom de chemin de ce
montage. Si cette option n'est pas définie, la taille maximale est
négociée avec le serveur. Dans la plupart des cas, cette
taille maximale est 255 caractères.
- Des versions précédentes de NFS ne
gèrent pas cette négociation. 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
indiquée (ou si c'est lock qui est choisi), le verrouillage
NLM est activé pour ce point de montage. Si on utilise l'option
nolock, les applications peuvent verrouiller les fichiers, mais ces
verrous n'ont de portée que pour les applications qui tournent sur
ce même client. Les applications distantes ne sont pas
informées de ces verrous.
- Le verrouillage NLM doit être
désactivé lors de l'utilisation de l'option nolock si
/var est monté à l'aide de NFS, parce que /var
contient des fichiers utilisés par l'implémentation de NLM
sous Linux. L'usage de nolock est aussi requis lors des montages de
partages de serveurs NFS ne gérant pas le protocole NLM.
-
cto / nocto
- Indiquer s'il faut utiliser la sémantique de
cohérence de cache close-to-open. Si aucune option n'est
indiquée (ou si c'est cto qui est choisi), le client utilise
la sémantique de cohérence de cache close-to-open. Si c'est
l'option nocto qui est choisie, le client utilise une heuristique
non standard pour savoir quand les fichiers ont changé sur le
serveur.
- L'utilisation de l'option nocto peut
améliorer les performances des montages en lecture seule, mais
devrait être limitée au cas où les données sur
le serveur ne changent qu'occasionnellement. La section
COHÉRENCE DES DONNÉES ET DES
MÉTADONNÉES expose le comportement de cette option en
détails.
-
acl / noacl
- Indiquer s'il faut utiliser le protocole auxiliaire NFSACL
sur ce point de montage. Le protocole auxiliaire NFSACL est un protocole
propriétaire mis en œuvre dans Solaris et qui gère
les listes de contrôle d'accès (les ACLs). NSFACL n'est
jamais devenu un élément standard de la spécification
du protocole NFS.
- Si ni acl ni noacl ne sont
précisées, le client NFS négocie avec le serveur afin
de savoir si le protocole NFSACL est actif, et l'utilise dans ce cas. La
désactivation du protocole auxiliaire NFSACL est parfois rendue
nécessaire quand la négociation pose des problèmes
sur le client ou sur le serveur. Consultez la section
CONSIDÉRATIONS DE SÉCURITÉ pour plus de
détails.
-
local_lock=mécanisme
- Précise si le verrouillage local doit être
utilisé pour les mécanismes flock, POSIX, ou les deux.
mechanism peut être all, flock, posix,
or 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'ont de portée que pour les applications qui tournent sur
ce même client. Les applications distantes ne sont pas
informées de ces verrous.
- Si cette option n'est pas précisée, ou si
none est précisé, le client suppose que les verrous
ne sont pas locaux.
- Si all est spécifié, le client suppose
que les deux types de verrous flock et POSIX sont locaux.
- Si flock est spécifié, le client
suppose que seuls les verrous flock sont locaux, et utilise le protocole
NLM associé pour verrouiller les fichiers quand les verrous POSIX
sont utilisés.
- Si posix est spécifié, le client
suppose que les verrous POSIX sont locaux, et utilise le protocole NLM
associé pour verrouiller les fichiers quand les verrous flock sont
utilisés.
- Pour supporter le comportement flock de façon
semblable à celui des clients NFS < 2.6.12, utiliser
'local_lock= flock'. Cette option est requise lors de l'exportation des
montages NFS à l'aide de Samba comme des cartes Windows Samba
partagé en mode verrouillé flock. Puisque les clients NFS
> 2.6.12 utilise flock en émulant les verrous POSIX, il y aura
un conflit de verrous.
- NOTE : Quand elles sont utilisées ensemble,
l'option de montage 'local_lock' sera écrasée par l'option
de montage 'nolock'/'lock'.
Use these options, along with the options in the first subsection above, for NFS
version 4.0 and newer.
-
proto=idreseau
- The netid determines the transport that is used to
communicate with the NFS server. Supported options are tcp,
tcp6, rdma, and rdma6. tcp6 use IPv6 addresses
and is only available if support for TI-RPC is built in. Both others use
IPv4 addresses.
- Les serveurs NFS version 4 doivent prendre en charge
TCP, donc si cette option n'est pas précisée, le client NFS
utilise le protocole TCP. Veuillez vous référer à la
section MÉTHODES DE TRANSPORT pour plus de
détails.
-
minorversion=n
- Specifies the protocol minor version number. NFSv4
introduces "minor versioning," where NFS protocol enhancements
can be introduced without bumping the NFS protocol version number. Before
kernel 2.6.38, the minor version is always zero, and this option is not
recognized. After this kernel, specifying "minorversion=1"
enables a number of advanced features, such as NFSv4 sessions.
- Recent kernels allow the minor version to be specified
using the vers= option. For example, specifying vers=4.1 is
the same as specifying vers=4,minorversion=1.
-
port=n
- Valeur numérique du port du service NFS sur le
serveur. Si le service NFS du serveur n'est pas accessible sur le port
indiqué, la requête de montage échoue.
- Si cette option de montage n'est pas définie, le
client NFS utilisera le numéro de port standard de NFS (2049) sans
vérifier de prime abord le service rpcbind du serveur. Cette option
permet à un client NFS version 4 de contacter un serveur NFS
version 4 à travers un pare-feu qui bloquerait les
requêtes rpcbind.
- Si la valeur du port indiquée est 0, le client NFS
utilisera le numéro de port du service NFS publié par le
service rpcbind du serveur. La requête de montage échouera
si le service rpcbind du serveur n'est pas disponible, si le service NFS
du serveur n'est pas enregistré dans son service rpcbind, ou si le
service NFS du serveur n'est pas accessible sur le port
publié.
-
cto / nocto
- Indiquer s'il faut utiliser la sémantique de
cohérence du cache close-to-open pour les répertoires NFS de
ce point de montage. Si ni cto ni nocto ne sont
indiquées, la sémantique de cohérence du cache
close-to-open sera utilisée par défaut pour les
répertoires.
- La politique de mise en cache des données des
fichiers n'est pas concernée par cette option. La section
COHÉRENCE DES DONNÉES ET DES
MÉTADONNÉES décrit le comportement de cette
option en détails.
-
clientaddr=n.n.n.n
-
clientaddr=n:n:...:n
- Specifies a single IPv4 address (in dotted-quad form), or a
non-link-local IPv6 address, that the NFS client advertises to allow
servers to perform NFS version 4.0 callback requests against files on this
mount point. If the server is unable to establish callback connections to
clients, performance may degrade, or accesses to files may temporarily
hang. Can specify a value of IPv4_ANY (0.0.0.0) or equivalent IPv6 any
address which will signal to the NFS server that this NFS client does not
want delegations.
- Si cette option n'est pas indiquée, la commande
mount(8) essaie de découvrir automatiquement une adresse de
rappel (« callback ») appropriée. La
procédure de découverte automatique n'est cependant pas
parfaite. Dans le cas d'interfaces réseau multiples, de directives
de routages spéciales ou de typologie réseau atypique,
l'adresse exacte à utiliser pour les rappels peut ne pas
être triviale à déterminer.
- NFS protocol versions 4.1 and 4.2 use the
client-established TCP connection for callback requests, so do not require
the server to connect to the client. This option is therefore only affect
NFS version 4.0 mounts.
-
migration / nomigration
- Selects whether the client uses an identification string
that is compatible with NFSv4 Transparent State Migration (TSM). If the
mounted server supports NFSv4 migration with TSM, specify the
migration option.
- Some server features misbehave in the face of a
migration-compatible identification string. The nomigration option
retains the use of a traditional client indentification string which is
compatible with legacy NFS servers. This is also the behavior if neither
option is specified. A client's open and lock state cannot be migrated
transparently when it identifies itself via a traditional identification
string.
- This mount option has no effect with NFSv4 minor versions
newer than zero, which always use TSM-compatible client identification
strings.
Le type
nfs4 de système de fichiers est une ancienne syntaxe
précisant l'utilisation de NFSv4. Il peut toujours être
utilisé avec toutes les options spécifiques à NFSv4,
à l'exception de l'option de montage
nfsvers
Si la commande de montage est configurée pour, toutes les options de
montage décrites dans la section précédente peuvent
être configurées dans le fichier
/etc/nfsmount.conf.
Référez-vous à
nfsmount.conf(5) pour plus de
détails.
mount option. To mount using NFS version 3, use the
nfs file system type
and specify the
nfsvers=3 mount option. To mount using NFS version 4,
use either the
nfs file system type, with the
nfsvers=4 mount
option, or the
nfs4 file system type.
L'exemple de fichier
/etc/fstab qui suit permet à la commande
mount de négocier des valeurs par défaut convenables pour le
comportement NFS.
serveur:/export /mnt nfs defaults 0 0
This example shows how to mount using NFS version 4 over TCP with Kerberos 5
mutual authentication.
serveur:/export /mnt nfs4 sec=krb5 0 0
This example shows how to mount using NFS version 4 over TCP with Kerberos 5
privacy or data integrity mode.
server:/export /mnt nfs4 sec=krb5p:krb5i 0 0
Cet exemple peut servir à réaliser le montage de /usr grâce
à NFS.
serveur:/export /usr nfs ro,nolock,nocto,actimeo=3600 0 0
Cet exemple montre comment utiliser une adresse brute non locale IPv6.
[fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0
Les clients NFS envoient leurs requêtes aux serveurs NFS grâce aux
appels de procédures distantes (« Remote Procedure
Calls »), les
RPCs. Le client RPC découvre
automatiquement les entrées du service distant, gère
l'authentification requête par requête, ajuste les
paramètres des requêtes afin de gérer l'ordre des octets
sur le client et le serveur (« endianess »), et se
charge de la retransmission des requêtes qui pourraient s'être
perdues dans le réseau ou sur le serveur. Les requêtes et les
réponses RPC circulent sur un protocole de transport réseau.
Dans la plupart des cas, la commande
mount(8), le client NFS et le
serveur NFS peuvent négocier automatiquement les valeurs
adéquates de taille pour les transferts de données et de
transport pour un point de montage. Cependant, dans certains cas, il peut
être efficace d'indiquer explicitement ces valeurs grâce aux
options de montage.
Anciennement, les clients NFS se servaient uniquement du transport UDP pour
transmettre des requêtes aux serveurs. Bien que son
implémentation soit simple, NFS sur UDP a de nombreuses limitations qui
l'empêchent d'obtenir de bonnes performances et un fonctionnement
fluide dans certains environnements de déploiement courants. Un taux de
paquets perdus même insignifiant entraîne la perte de
requêtes NFS complètes. On règle alors
généralement le délai de dépassement
(« timeout ») à une valeur
inférieure à la seconde afin que les clients puissent
récupérer rapidement en cas de requêtes rejetées.
Cela peut entraîner une surcharge du trafic réseau et du
serveur.
Cependant, UDP peut être assez efficace grâce à des
réglages spécifiques lorsque le MTU du réseau
dépasse la taille de transfert de données de NFS (par exemple
dans les environnements réseau qui utilisent les trames Ethernet
Jumbo). Dans ces cas, il est judicieux d'adapter les réglages
rsize et
wsize de façon à ce que chaque
requête de lecture ou d'écriture NFS soit contenue dans quelques
trames du réseau (voire même dans une seule trame). Cela
réduit la probabilité qu'une perte d'une simple trame
réseau de la taille de la MTU entraîne la perte complète
d'un grande requête en lecture ou écriture.
TCP est le protocole de transport utilisé par défaut dans toutes
les implémentations modernes de NFS. Il est efficace dans pratiquement
tous les environnements réseau concevables et offre d'excellentes
garanties contre la corruption de données que pourrait entraîner
un incident réseau. TCP est souvent requis pour accéder à
un serveur à travers un pare-feu.
Dans des conditions normales, les réseaux rejettent des paquets bien plus
souvent que les serveurs NFS ne rejettent de requêtes. C'est pourquoi
un réglage agressif de délai de dépassement
(« time-out ») de retransmission pour NFS sur TCP
est inutile. Les réglages habituels de délai de
dépassement pour NFS sur TCP varient entre une et dix minutes.
Après qu'un client a terminé ses retransmissions (la valeur de
l'option
retrans de mount), il considère que le réseau a
subi une panne et tente de se reconnecter au serveur grâce à une
nouvelle interface de connexion (« socket »).
Puisque TCP fiabilise le transport de données sur le réseau,
rsize et
wsize peuvent en toute sécurité permettre
par défaut la plus grande valeur gérée à la fois
par le client et par le serveur, indépendamment de la taille du MTU du
réseau.
This section applies only to NFS version 3 mounts since NFS version 4 does not
use a separate protocol for mount requests.
Le client Linux peut utiliser différents modes de transfert pour
contacter le service rpcbind d'un serveur, son service mountd, son
gestionnaire de verrou réseau (NLM) et son service NFS. Le mode de
transport utilisé par le client NFS de Linux pour chaque point de
montage dépend des options passées à mount, qui incluent
proto,
mountproto udp et
tcp.
Le client envoie des notifications au gestionnaire réseau de statut
(NSM : « network status manager ») à
l'aide d'UDP, quel que soit le mode de transfert précisé. Il
écoute cependant les notifications NSM du serveur à la fois sur
UDP et TCP. Le protocole gérant la liste de contrôle
d'accès à NFS (NFACL : « nfs access control
list ») utilise le même mode de transfert que le service
NFS principal.
Si aucune option n'est précisée quant au mode de transfert, le
client NFS Linux utilise UDP pour contacter le service mountd du server, et
TCP pour contacter ses services NLM et NFS par défaut.
Si le serveur ne gère 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 géré par le client ou est mal
configuré, la requête de montage échoue. Si l'option
bg a été passée, la commande mount passe en
arrière-plan et continue d'essayer la requête de montage
demandée.
Quand l'une des options
proto,
udp ou
tcp est passée
mais que
mountproto ne l'est pas, le mode de transfert demandé
est utilisé à la fois pour contacter le service mountd du
serveur et ses services NLM et NFS.
Si l'option
mountproto est passée mais que ni
proto, ni
udp et ni
tcp n'est passée alors le mode demandé
est utilisé pour la requête mount initiale, mais la commande
mount essaye de découvrir quel mode de transfert est pris en charge
pour le protocole NFS, et préférera TCP si les deux modes sont
implémentés.
Si
mountproto et
proto (ou
udp ou
tcp) sont
passés en même temps, le mode de transport indiqué
à l'option
mountproto est utilisé pour la requête
initiale de mountd, et le mode indiqué à
proto (ou
udp ou
tcp) est utilisé pour NFS, quel que soit l'ordre
de ces options. Le programme ne cherchera pas à trouver les services si
ces options sont données.
Si l'une des options
proto,
udp,
tcp ou
mountproto
est passée plus d'une fois dans une même commande, alors la
valeur retenue sera celle la plus à droite.
Utiliser NFS sur UDP avec des connexions haut débit comme Gigabit
peut
causer des corruptions de données silencieuses.
Le problème peut être déclenché lors de fortes
charges, et est causé par des difficultés dans le
réassemblage de fragments IP. Les lectures et écritures par NFS
transmettent typiquement des paquets UDP de 4 kilooctets ou plus, qui
doivent être cassés en plusieurs fragments pour être
envoyés sur le lien Ethernet, pour lequel la taille des paquets est
limitée à 1500 octets par défaut. Ce processus a
lieu au niveau de la couche réseau IP et est appelé
fragmentation.
Afin d'identifier les fragments qui proviennent du même paquet, IP
attribue un identifiant IP (
IP ID) sur 16 bits à chaque
paquet. Les fragments générés à partir du
même paquet UPD auront le même identifiant IP. Le système
destinataire récupère ces fragments et les combine pour reformer
les paquets UPD originaux. Ce processus est appelé réassemblage.
Le délai d'expiration par défaut pour le réassemblage de
paquets est de 30 secondes. Si la pile réseau ne reçoit
pas tous les fragments d'un paquet donné pendant cet intervalle de
temps, elle suppose que les fragments manquants se sont perdus et rejette ceux
qui ont déjà été reçus.
Le problème que cela crée sur des connexions à haut
débit est dû au fait qu'il est possible d'envoyer plus de
655356 paquets en 30 secondes. En fait, avec un trafic dense
NFS, les identifiants IP se répètent au bout d'environ
5 secondes.
Cela a de sérieux effets sur le réassemblage : si un
fragment se perd, un autre fragment
d'un paquet différent mais
avec le
même identifiant IP arrivera avant l'expiration au bout
de 30 secondes, et la pile réseau combinera ces fragments pour
former un nouveau paquet. La plupart du temps, les couches réseau
au-dessus d'IP détecteront ce réassemblage non assorti
— dans le cas d'UPD, la somme de contrôle UDP sur
16 bits sur la charge utile du paquet ne correspondra pas, et UDP
rejettera le mauvais paquet.
Cependant, comme la somme de contrôle UDP est sur uniquement
16 bits, il y a une chance sur 655356 qu'elle coïncide
même si la charge utile du paquet est complètement
aléatoire (ce qui très souvent n'est pas vrai). Si tel est le
cas, une corruption de données silencieuse se sera produite.
Cette possibilité doit être prise au sérieux, au moins sur
Ethernet Gigabit. Les débits réseau de 100 Mbit/s
devraient être considérés comme moins
problématiques, car dans la plupart des situations, l'épuisement
des identifiants IP prendra bien plus que 30 secondes.
Il est donc fortement recommandé d'utiliser
NFS sur TCP là
où c'est possible, car TCP n'effectue pas de fragmentation.
Si vous devez absolument utiliser NFS sur UDP sur un réseau Gigabit
Ethernet, quelques actions peuvent être effectuées pour limiter
le problème et réduire la probabilité de
corruption :
- trames Jumbo :
- Beaucoup de cartes réseau Gigabit sont capables de
transmettre des trames plus grandes que la limite traditionnelle sur
Ethernet de 1500 octets (typiquement 9000 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
sûr, cela n'est possible que si toutes les stations
impliquées gèrent les trames Jumbo.
- Pour activer l'envoi de trames Jumbo sur une machine avec
une carte réseau qui les gère, il suffit de configurer
l'interface avec une valeur MTU de 9000.
- diminution du délai avant expiration de
réassemblage :
- Le réassemblage incorrect de fragments peut
être aussi évité en diminuant ce délai sous le
temps nécessaire à la réinitialisation des
identifiants IP. Pour ce faire, écrivez simplement la nouvelle
valeur du délai (en seconde) dans le fichier
/proc/sys/net/ipv4/ipfrag_time.
- Une valeur de 2 secondes diminuera fortement la
probabilité d'une collision d'identifiants IP sur un seul lien
Gigabit, tout en permettant un délai d'expiration raisonnable lors
de la réception d'un trafic fragmenté depuis des serveurs
distants.
Some modern cluster file systems provide perfect cache coherence among their
clients. Perfect cache coherence among disparate NFS clients is expensive to
achieve, especially on wide area networks. As such, NFS settles for weaker
cache coherence that satisfies the requirements of most file sharing types.
Typically file sharing is completely sequential. First client A opens a file,
writes something to it, then closes it. Then client B opens the same file, and
reads the changes.
When an application opens a file stored on an NFS version 3 server, the NFS
client checks that the file exists on the server and is permitted to the
opener by sending a GETATTR or ACCESS request. The NFS client sends these
requests regardless of the freshness of the file's cached attributes.
When the application closes the file, the NFS client writes back any pending
changes to the file so that the next opener can view the changes. This also
gives the NFS client an opportunity to report write errors to the application
via the return code from
close(2).
The behavior of checking at open time and flushing at close time is referred to
as
close-to-open cache consistency, or
CTO. It can be disabled
for an entire mount point using the
nocto mount option.
Il y a toujours des cas dans lesquels le cache de données du client
contient des données incohérentes. Dans la version 3 du
protocole NFS est apparue la « faible cohérence de
cache » (appelée aussi WCC), offrant une méthode
efficace de vérification des attributs d'un fichier avant et
après une requête unique. Cela permet à un client une
meilleure perception des modifications qui ont pu être
réalisées par les autres clients.
Quand un client génère beaucoup d'opérations concomitantes
qui modifient le même fichier au même moment (par exemple
grâce à des écritures asynchrones en
arrière-plan), il est difficile de savoir si le fichier a
été modifié par ce client ou par un autre.
L'utilisation de l'option
noac de mount permet de réaliser la
cohérence de la mémorisation (cache) des attributs pour de
multiples clients. Pratiquement toutes les opérations de système
de fichiers vérifient les informations d'attributs de fichiers. Le
client garde cette information en mémoire (cache) pendant un certain
temps afin de réduire la charge du serveur et du réseau. Quand
noac est activée, le cache des attributs de fichier est
désactivé sur le client et chaque opération qui doit
vérifier les attributs des fichiers doit impérativement
s'adresser au serveur. Ceci permet au client de voir rapidement les
modifications sur un fichier, en contrepartie d'une augmentation importante
des opérations réseaux.
Soyez attentif à ne pas confondre l'option
noac avec
« pas de mémorisation de données (no data
caching) ». L'option
noac de mount empêche la mise
en cache par le client des métadonnées du fichier, mais il
existe toujours des cas dans lesquels des incohérences de
données cachées peuvent survenir entre le client et le serveur.
Le protocole NFS n'a pas été conçu pour gérer la
cohérence absolue des caches pour des grappes (clusters) de
systèmes de fichiers sans qu'il soit nécessaire d'utiliser des
types particuliers de sérialisation au niveau applicatif. Si la
cohérence absolue du cache est nécessaire aux clients, les
applications devront utiliser le verrouillage de fichiers
(« file locking »). D'autre part, les applications
pourront aussi utiliser le drapeau O_DIRECT lors de l'ouverture des fichiers
afin de désactiver totalement la mise en cache des données.
NFS servers are responsible for managing file and directory timestamps (
atime,
ctime, and
mtime). When a file is accessed or
updated on an NFS server, the file's timestamps are updated just like they
would be on a filesystem local to an application.
NFS clients cache file attributes, including timestamps. A file's timestamps are
updated on NFS clients when its attributes are retrieved from the NFS server.
Thus there may be some delay before timestamp updates on an NFS server appear
to applications on NFS clients.
To comply with the POSIX filesystem standard, the Linux NFS client relies on NFS
servers to keep a file's
mtime and
ctime timestamps properly up
to date. It does this by flushing local data changes to the server before
reporting
mtime to applications via system calls such as
stat(2).
The Linux client handles
atime updates more loosely, however. NFS clients
maintain good performance by caching data, but that means that application
reads, which normally update
atime, are not reflected to the server
where a file's
atime is actually maintained.
Because of this caching behavior, the Linux NFS client does not support generic
atime-related mount options. See
mount(8) for details on these options.
In particular, the
atime/
noatime,
diratime/
nodiratime,
relatime/
norelatime, and
strictatime/
nostrictatime mount options have no effect on NFS
mounts.
/proc/mounts may report that the
relatime mount option is set on
NFS mounts, but in fact the
atime semantics are always as described
here, and are not like
relatime semantics.
Le client NFS Linux garde en cache les résultats d'une requête NFS
LOOKUP. Si la requête pointe sur un répertoire existant sur le
serveur, le résultat sera noté
positif. Sinon, si le
répertoire n'existe pas (c'est-à-dire si le serveur retourne
ENOENT), le résultat sera noté
négatif.
Afin de détecter l'ajout ou la suppression de répertoires sur le
serveur, le client NFS Linux regarde la date de modification
(« mtime ») du répertoire. Si le client
détecte un changement dans cette date, le client supprime tous les
résultats LOOKUP encore en cache concernant ce répertoire. Comme
la date de modification est un attribut conservé en cache, il est
possible qu'un peu de temps se passe avant que le client remarque le
changement. Référez-vous aux descriptions des options de montage
acdirmin,
acdirmax et
noac pour plus d'informations quant
à la manière dont le temps de modification est mis en cache.
Mettre en cache les entrées des répertoires améliore les
performances des applications qui ne partagent pas de fichiers avec des
applications sur un autre client. L'utilisation d'informations en cache sur
des répertoires, cependant, peut interférer avec des
applications qui tournent simultanément sur de nombreux clients et qui
doivent détecter rapidement la création ou la suppression de
fichiers. L'option de montage
lookupcache permet de personnaliser
certains comportements de mise en cache de répertoires.
Avant la version 2.6.28 du noyau, le client NFS Linux cherchait uniquement les
résultats de recherches positifs. Cela permettait aux applications de
détecter rapidement de nouvelles entrées de répertoires
créées par d'autres clients, tout en fournissant une partie des
bénéfices dus à la mise en cache. Si une application
dépend de cet ancien comportement, vous pouvez utiliser l'option
lookupcache=positive.
Si le client ignore son cache et valide toutes les requêtes de recherche
avec le serveur, il peut alors détecter immédiatement toute
création ou suppression de répertoire par un autre client. Vous
pouvez forcer ce comportement avec l'option
lookupcache=none. L'absence
de mise en cache des répertoires entraîne une augmentation du
nombre de requêtes NFS, et donc une perte de performances.
Empêcher 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 manière dont le client NFS met en cache les attributs d'un fichier.
Le client NFS gère l'option de montage
sync différemment
que d'autres systèmes de fichiers (consultez
mount(8) pour une
description générique des options de montage
sync et
async). Si ni
sync ni
async ne sont indiquées (ou
si l'option
async est indiquée), le client NFS retarde l'envoi
au serveur des ordres d'écriture des applications jusqu'à ce que
l'un de ces événements survienne :
- La saturation en mémoire entraîne une demande
de ressources mémoire au système.
- Une application met à jour
(« flush ») les données d'un fichier de
manière explicite avec sync(2), msync(2) ou
fsync(3).
- Une application ferme un fichier avec close(2).
- Le fichier est verrouillé/déverrouillé
grâce à fcntl(2).
Autrement dit, dans les conditions normales d'utilisation, des données
écrites par une application peuvent ne pas apparaître
instantanément sur le serveur qui héberge le fichier.
Si l'option
sync est précisée pour un point de montage,
tout appel système qui écrit des données dans des
fichiers de ce point de montage entraîne la purge des données
sur le serveur avant de revenir en espace utilisateur (« user
space »). Cela offre une meilleure cohérence du cache des
données, mais a un impact certain sur les performances.
Les applications peuvent utiliser le drapeau d'ouverture O_SYNC afin que les
écritures d'un fichier précis soient immédiatement prises
en compte par le serveur, et ce sans l'utilisation de l'option
sync de
mount.
The Network Lock Manager protocol is a separate sideband protocol used to manage
file locks in NFS version 3. To support lock recovery after a client or server
reboot, a second sideband protocol -- known as the Network Status Manager
protocol -- is also required. In NFS version 4, file locking is supported
directly in the main NFS protocol, and the NLM and NSM sideband protocols are
not used.
Dans la plupart des cas, les services NLM et NSM sont démarrés
automatiquement et aucune configuration additionnelle n'est requise. La
configuration en noms de domaine complètement définis (FQDN) de
tous les clients NFS est nécessaire pour permettre aux serveurs NFS de
retrouver leurs clients, afin de les prévenir en cas de
redémarrage.
NLM ne gère que l'annonce de verrouillage de fichiers. Pour verrouiller
les fichiers NFS, il faut utiliser
fcntl(2) avec les commandes F_GETL
et F_SETL. Le client NFS convertit les verrous de fichiers obtenus
grâce à
flock(2) en annonces de verrouillage.
Lors du montage de serveurs ne gérant pas le protocole NLM ou lorsqu'on
monte un serveur NFS à travers un pare-feu qui bloque le port du
service NLM, il faut utiliser l'option
nolock de mount. Le verrouillage
NLM doit être désactivé grâce à l'option
nolock lorsqu'on utilise NFS pour monter
/var, puisque
/var contient les fichiers utilisés par NLM dans son
implémentation sous Linux.
L'utilisation de l'option
nolock est parfois conseillée pour
améliorer les performances d'une application propriétaire qui ne
tourne que sur un seul client mais qui utilise intensément les verrous
de fichiers.
Le comportement du cache des données et des métadonnées des
clients NFS version 4 est identique à celui des
précédentes versions. Toutefois, la version 4 de NFS
offre deux nouveaux dispositifs pour améliorer le comportement du
cache :
attributs de changement et
délégation
de fichier.
L'
attribut de changement est un nouvel élément des
métadonnées de fichiers et de répertoires NFS qui
enregistre les modifications des données. Il se substitue à
l'utilisation de l'horodatage des modifications et changements du fichier pour
offrir aux clients la validation du contenu de leur cache. Cependant, ces
attributs de changement ne sont pas liés à la gestion de
l'horodatage ni sur le client ni sur le serveur.
La
délégation de fichier est un contrat qui lie un client
NFS version 4 et le serveur, offrant temporairement au client le
traitement d'un fichier comme s'il était le seul à y
accéder. Le serveur s'engage à prévenir le client
(grâce à une requête de rappel, ou
« callback ») si un autre client tente
d'accéder à ce même fichier. Une fois qu'un fichier a
été délégué à un client, ce client
peut mémoriser (mettre en cache) les données et les
métadonnées de ce fichier de façon agressive sans avoir
à contacter le serveur.
Il y a deux types de délégations :
lecture et
écriture. Une délégation en
lecture indique
que le serveur avertira le client si d'autres clients veulent écrire
dans ce fichier. Une délégation en
écriture
indique que le client sera prévenu des tentatives de lecture ou
d'écriture.
Les serveurs offrent les délégations de fichier sitôt qu'un
fichier est ouvert et peuvent annuler ces délégations n'importe
quand dès lors qu'un autre client désire accéder à
un fichier d'une manière qui entre en conflit avec les
délégations déjà attribuées. Les
délégations de répertoires ne sont pas
gérées.
Afin de pouvoir gérer les alertes de délégations
(« delegation callback »), le serveur
vérifie le chemin retour vers le client au moment du contact initial de
celui-ci. Si le retour vers le client ne peut pas être établi,
le serveur n'attribue purement et simplement aucune délégation
à ce client.
Les serveurs NFS contrôlent l'accès aux données des
fichiers, mais leur offre de gestion de l'authentification des requêtes
NFS dépend de leur implémentation des RPC. Les contrôles
d'accès NFS traditionnels imitent les contrôles d'accès
binaires standards offerts par les systèmes de fichiers locaux.
L'authentification RPC traditionnelle utilise un nombre pour
représenter chaque utilisateur (normalement l'uid propre à cet
utilisateur), un nombre pour représenter le groupe de cet utilisateur
(le gid de l'utilisateur) et un ensemble d'au maximum 16 nombres de
groupes additionnels pour représenter les groupes auxquels cet
utilisateur peut appartenir.
Traditionnellement, les données du fichier et l'ID de l'utilisateur ne
sont pas chiffrées sur le réseau (en clair). Qui plus est, les
versions 2 et 3 de NFS utilisent des protocoles auxiliaires
séparés pour le montage, le verrouillage et le
déverrouillage des fichiers, et pour renvoyer les valeurs de retour
système des clients et serveurs. Ces protocoles auxiliaires n'utilisent
pas d'authentification.
En plus d'avoir intégré ces deux protocoles auxiliaires dans le
protocole NFS principal, la version 4 de NFS offre des formes plus
avancées de contrôle d'accès, d'authentification, et de
protection lors du transfert des données. La spécification de la
version 4 de NFS requiert une prise en charge de l'authentification
renforcée, et les divers types de sécurité permettant le
contrôle d'intégrité et le chiffrement à l'aide de
RPC. Puisque la version 4 de NFS ajoute les fonctionnalités de
ces protocoles au cœur du protocole NFS, les nouvelles
caractéristiques de sécurité s'appliquent à toutes
les opérations de NFS version 4, incluant donc le montage, le
verrouillage des fichiers, et ainsi de suite. L'authentification RPCGSS peut
aussi être utilisée avec les versions 2 et 3 de NFS, mais
ne protège pas les protocoles associés.
The
sec mount option specifies the security flavor used for operations on
behalf of users on that NFS mount point. Specifying
sec=krb5 provides
cryptographic proof of a user's identity in each RPC request. This provides
strong verification of the identity of users accessing data on the server.
Note that additional configuration besides adding this mount option is
required in order to enable Kerberos security. Refer to the
rpc.gssd(8)
man page for details.
Deux dispositifs additionnels de la sécurité Kerberos sont pris en
charge :
krb5i et
krb5p. Le dispositif de
sécurité
krb5i offre une garantie de chiffrement fort
contre la falsification des données pour chaque requête RPC. Le
dispositif de sécurité
krb5p chiffre chaque
requête RPC afin d'éviter qu'elle soit exposée pendant
son transfert sur le réseau. Toutefois, le chiffrement ou la
vérification de l'intégrité entraînent des baisses
de performance. D'autres formes de sécurité par chiffrement sont
aussi prises en charge.
Le protocole de la version 4 de NFS permet à un client de
renégocier le type de sécurité lorsqu'un client entre sur
un nouveau système de fichiers sur le serveur. Le type nouvellement
négocié ne concerne que le nouveau système de fichiers.
Une telle négociation se produit typiquement lorsqu'un client passe d'un
pseudo-système de fichiers du serveur à un des systèmes
de fichiers physiques exportés par le serveur, qui ont souvent des
paramètres de sécurité plus restrictifs que les
pseudo-systèmes de fichiers.
In NFS version 4, a lease is a period during which a server irrevocably grants a
client file locks. Once the lease expires, the server may revoke those locks.
Clients periodically renew their leases to prevent lock revocation.
After an NFS version 4 server reboots, each client tells the server about
existing file open and lock state under its lease before operation can
continue. If a client reboots, the server frees all open and lock state
associated with that client's lease.
When establishing a lease, therefore, a client must identify itself to a server.
Each client presents an arbitrary string to distinguish itself from other
clients. The client administrator can supplement the default identity string
using the
nfs4.nfs4_unique_id module parameter to avoid collisions with
other client identity strings.
A client also uses a unique security flavor and principal when it establishes
its lease. If two clients present the same identity string, a server can use
client principals to distinguish between them, thus securely preventing one
client from interfering with the other's lease.
The Linux NFS client establishes one lease on each NFS version 4 server. Lease
management operations, such as lease renewal, are not done on behalf of a
particular file, lock, user, or mount point, but on behalf of the client that
owns that lease. A client uses a consistent identity string, security flavor,
and principal across client reboots to ensure that the server can promptly
reap expired lease state.
When Kerberos is configured on a Linux NFS client (i.e., there is a
/etc/krb5.keytab on that client), the client attempts to use a Kerberos
security flavor for its lease management operations. Kerberos provides secure
authentication of each client. By default, the client uses the
host/ or
nfs/ service principal in its
/etc/krb5.keytab for this purpose,
as described in
rpc.gssd(8).
If the client has Kerberos configured, but the server does not, or if the client
does not have a keytab or the requisite service principals, the client uses
AUTH_SYS and UID 0 for lease management.
Le client NFS communique normalement avec le serveur par des tuyaux
réseaux (network sockets). À chaque bout du tuyau est
associé un port qui est un simple nombre entre 1 et 65535, ce qui
permet de distinguer des tuyaux pointant sur la même adresse IP. Un
tuyau est identifié de manière unique par un n-uplet comprenant
le protocole de passage (TCP ou UDP) et les ports et adresses IP de chaque
bout.
Le client NFS peut choisir n'importe quel port d'origine pour ses tuyaux, mais
il choisit en général un port
privilégié
(c'est-à-dire avec une valeur inférieure à 1024). Seul un
processus tournant avec des droits du superutilisateur peut créer un
tuyau à partir d'un port privilégié.
La fourchette des ports potentiellement choisis est configurée par une
paire de sysctls pour éviter l'utilisation de ports bien connus, tel
celui de SSH. Cela signifie que le nombre de ports source potentiels pour le
client NFS, et donc pour le nombre de connexions par tuyau disponible à
un moment donné est en pratique de l'ordre d'une centaine.
Comme décrit plus haut, le schéma d'authentification NFS
traditionnel (connu sous le nom d'AUTH_SYS) compte sur l'envoi d'UID et de GID
locaux pour identifier les utilisateurs à l'origine de requêtes.
Un serveur NFS suppose que si une connexion provient d'un port non
privilégié, les numéros UID et GID de la requête
NFS ont déjà été vérifiés par le
noyau du client ou tout autre programme système local. Ce
système est facile à contourner, mais sur un réseau
sécurisé d'ordinateurs de confiance, c'est parfaitement
adapté.
En gros, un tuyau est utilisé pour chaque point de montage NFS. Si un
client peut aussi utiliser un port source non privilégié, le
nombre de tuyaux autorisés (et donc le nombre maximal de points de
montage en parallèles) sera beaucoup plus important.
Utiliser un port source non privilégié peut quelque peu
compromettre la sécurité du serveur, car n'importe quel
utilisateur d'un point de montage sur AUTH_SYS peut maintenant se faire passer
pour un autre comme source de la requête. C'est pourquoi les serveurs
NFS ne le prennent pas en charge par défaut. En règle
générale, ils l'autorisent explicitement à l'aide d'une
option de partage.
Pour garder un bon niveau de sécurité tout en ouvrant un maximum
de points de montage, il est préférable d'autoriser les
connexions clients sur un port non privilégié seulement si le
serveur et le client utilisent tous deux une authentification forte, comme
celle fournie par Kerberos.
Un pare-feu peut se trouver entre un client NFS et le serveur, ou alors le
client ou le serveur peuvent bloquer certains de leurs propres ports
grâce à des règles de filtrage IP. Il est toujours
possible de monter un serveur NFS à travers un pare-feu, bien que les
mécanismes de découverte automatique des terminaisons
d'accès (« endpoints ») de la commande
mount(8) peuvent ne pas fonctionner. Il vous faudra alors fournir des
détails spécifiques à ces terminaisons d'accès
(« endpoints ») grâce aux options de mount.
Les serveurs NFS lancent habituellement un service (daemon) portmapper ou
rpcbind pour annoncer aux clients les terminaisons (endpoints) des services.
Les clients se servent du démon rpcbind pour déterminer :
- Le port réseau utilisé par chaque service
basé sur les RPC
- Le protocole de transport utilisé par chaque service
basé sur les RPC
Le démon rpcbind utilise un port bien connu (111) afin d'aider les
clients à trouver la terminaison (endpoint) d'un service. Bien que NFS
utilise souvent un numéro de port standard (2049), des services
auxiliaires tels que NLM peuvent choisir au hasard des numéros de port
inutilisés.
Les configurations habituelles des pare-feu bloquent le port bien connu de
rpcbind. En l'absence du service rpcbind, l'administrateur du serveur
définit un numéro de port pour les services liés à
NFS afin que le pare-feu puisse permettre l'accès aux ports des
services spécifiques NFS. Les administrateurs des clients pourront
alors indiquer le numéro du port du service mountd grâce
à l'option
mountport de la commande
mount(8). Il peut
être nécessaire d'imposer l'utilisation de TCP ou d'UDP si le
pare-feu bloque l'un de ces transports.
Solaris permet aux clients NFS version 3 l'accès direct aux Access
Control Lists (ACL) POSIX stockés dans son système de fichiers
local. Ce protocole auxiliaire propriétaire, connu sous le nom de
NFSACL, offre un contrôle d'accès plus riche que le mode
binaire. Linux implémente ce protocole dans un but de
compatibilité avec l'implémentation NFS de Solaris. Cependant,
le protocole NFSACL n'est jamais devenu une partie standard de la
spécification NFS version 3.
La spécification de NFS version 4 impose une nouvelle version des
Access Control Lists qui sont sémantiquement 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 mélange à la fois les ACL POSIX et NFS
version 4.
Les options de montage générique comme
rw et
sync
peuvent être modifiées par les points de montage utilisant
l'option
remount. Voir
mount(8) pour plus d'informations sur les
options génériques de montage.
Sauf quelques exceptions, les options spécifiques à NFS ne peuvent
pas être modifiées pendant un remontage. Par exemple, le
transport sous-jacent ou la version NFS ne peuvent pas être
changés par un remontage.
Effectuer un remontage sur un système de fichiers NFS monté avec
l'option
noac peut avoir des conséquences inattendues. L'option
noac est une combinaison de l'option générique
sync et de l'option spécifique NFS
actimeo=0.
Pour les points de montage qui utilisent NFS versions 2 ou 3, la
sous-commande de démontage NFS dépend de la connaissance de
l'ensemble initial des options de montage utilisées pour effectuer
l'opération MNT. Ces options sont stockées sur le disque par la
sous-commande de montage NFS, et peuvent être effacées par un
remontage.
Afin de s'assurer que les options de montage enregistrées ne sont pas
effacées lors d'un remontage, il faut spécifier au remontage le
répertoire de montage local, ou le serveur hôte 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
déjà enregistrées sur le disque pour le serveur NFS
monté dans /mnt.
- /etc/fstab
- Table des systèmes de fichiers
- /etc/nfsmount.conf
- Fichier de configuration pour les montages NFS
Le client NFS antérieur à 2.4.7 ne gérait pas NFS sur TCP.
Le client NFS antérieur à 2.4.20 utilisait une heuristique pour
savoir si les données mémorisées d'un fichier (en cache)
étaient toujours valides plutôt qu'utiliser la méthode
standard de cohérence de cache close-to-open décrite ci-dessus.
Depuis la version 2.4.22, le client NFS utilise une estimation RTT de
type Van Jacobsen pour définir les délais de dépassement
de temps (timeout) lorsqu'il utilise NFS sur UDP.
Le client NFS Linux antérieur à 2.6.0 ne gérait pas NFS
version 4.
Le client NFS antérieur à 2.6.8 n'utilisait les lectures et
écritures synchrones que lorsque les réglages de
rsize et
wsize étaient inférieurs à la taille des pages du
système.
The Linux client's support for protocol versions depend on whether the kernel
was built with options CONFIG_NFS_V2, CONFIG_NFS_V3, CONFIG_NFS_V4,
CONFIG_NFS_V4_1, and CONFIG_NFS_V4_2.
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 spécification UDP.
RFC 793 concernant la spécification TCP.
RFC 1813 concernant la spécification de NFS version 3.
RFC 1832 concernant la spécification XDR.
RFC 1833 concernant la spécification RPC bind.
RFC 2203 concernant la spécification du protocole de l'API GSS
RPCSEC.
RFC 7530 for the NFS version 4.0 specification.
RFC 5661 concernant la spécification de NFS version 4.1.
RFC 7862 for the NFS version 4.2 specification.
La traduction française de cette page de manuel a été
créée par Valéry Perrin
<
[email protected]>, Sylvain Cherrier
<
[email protected]>, Thomas Huriaux
<
[email protected]>, Dominique Simen
<
[email protected]>, Nicolas Sauzède
<
[email protected]>, Romain Doumenc <
[email protected]>, David
Prévot <
[email protected]>, Denis Mugnier
<
[email protected]> et Cédric Boutillier
<
[email protected]>
Cette traduction est une documentation libre ; veuillez vous reporter
à la
GNU
General Public License version 3 concernant les conditions de copie
et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message à
[email protected]