RFC 1813 - Spécification du protocole NFS Version 3 (NFS Version 3 Protocol Specification)
- Statut: Informational
- Publié: June 1995
- Stream: Legacy
- Errata: Pas d'errata
Résumé (Abstract)
Ce document décrit le protocole NFS version 3. Ce document est fourni afin que les personnes puissent écrire des implémentations compatibles.
Table des matières (Table of Contents)
- 1. Introduction
- 1.1 Scope of the NFS version 3 protocol (Portée du protocole NFS version 3)
- 1.2 Useful terms (Termes utiles)
- 1.3 Remote Procedure Call (Appel de procédure à distance)
- 1.4 External Data Representation (Représentation externe des données)
- 1.5 Authentication and Permission Checking (Authentification et vérification des permissions)
- 1.6 Philosophy (Philosophie)
- 1.7 Changes from the NFS version 2 protocol (Changements par rapport au protocole NFS version 2)
- 2. RPC Information (Informations RPC)
- 2.1 Authentication (Authentification)
- 2.2 Constants (Constantes)
- 2.3 Transport address (Adresse de transport)
- 2.4 Sizes (Tailles)
- 2.5 Basic Data Types (Types de données de base)
- 2.6 Defined Error Numbers (Numéros d'erreur définis)
- 3. Server Procedures (Procédures serveur)
- 3.1 General comments on attributes (Commentaires généraux sur les attributs)
- 3.2 General comments on filenames (Commentaires généraux sur les noms de fichiers)
- 3.3.0 NULL: Do nothing (Ne rien faire)
- 3.3.1 GETATTR: Get file attributes (Obtenir les attributs du fichier)
- 3.3.2 SETATTR: Set file attributes (Définir les attributs du fichier)
- 3.3.3 LOOKUP: Lookup filename (Rechercher un nom de fichier)
- 3.3.4 ACCESS: Check access permission (Vérifier les permissions d'accès)
- 3.3.5 READLINK: Read from symbolic link (Lire depuis un lien symbolique)
- 3.3.6 READ: Read from file (Lire depuis un fichier)
- 3.3.7 WRITE: Write to file (Écrire dans un fichier)
- 3.3.8 CREATE: Create a file (Créer un fichier)
- 3.3.9 MKDIR: Create a directory (Créer un répertoire)
- 3.3.10 SYMLINK: Create a symbolic link (Créer un lien symbolique)
- 3.3.11 MKNOD: Create a special device (Créer un périphérique spécial)
- 3.3.12 REMOVE: Remove a file (Supprimer un fichier)
- 3.3.13 RMDIR: Remove a directory (Supprimer un répertoire)
- 3.3.14 RENAME: Rename a file or directory (Renommer un fichier ou un répertoire)
- 3.3.15 LINK: Create link to an object (Créer un lien vers un objet)
- 3.3.16 READDIR: Read From directory (Lire depuis un répertoire)
- 3.3.17 READDIRPLUS: Extended read from directory (Lecture étendue depuis un répertoire)
- 3.3.18 FSSTAT: Get dynamic file system information (Obtenir les informations dynamiques du système de fichiers)
- 3.3.19 FSINFO: Get static file system information (Obtenir les informations statiques du système de fichiers)
- 3.3.20 PATHCONF: Retrieve POSIX information (Récupérer les informations POSIX)
- 3.3.21 COMMIT: Commit cached data on a server to stable storage (Valider les données en cache sur un serveur vers un stockage stable)
- 4. Implementation issues (Questions d'implémentation)
- 4.1 Multiple version support (Support de plusieurs versions)
- 4.2 Server/client relationship (Relation serveur/client)
- 4.3 Path name interpretation (Interprétation des noms de chemin)
- 4.4 Permission issues (Questions de permissions)
- 4.5 Duplicate request cache (Cache de requêtes en double)
- 4.6 File name component handling (Gestion des composants de nom de fichier)
- 4.7 Synchronous modifying operations (Opérations de modification synchrones)
- 4.8 Stable storage (Stockage stable)
- 4.9 Lookups and name resolution (Recherches et résolution de noms)
- 4.10 Adaptive retransmission (Retransmission adaptative)
- 4.11 Caching policies (Politiques de mise en cache)
- 4.12 Stable versus unstable writes (Écritures stables versus instables)
- 4.13 32 bit clients/servers and 64 bit clients/servers (Clients/serveurs 32 bits et clients/serveurs 64 bits)
- 5. Appendix I: Mount protocol (Annexe I : Protocole de montage)
- 5.1 RPC Information (Informations RPC)
- 5.2 Server Procedures (Procédures serveur)
- 6. Appendix II: Lock manager protocol (Annexe II : Protocole du gestionnaire de verrous)
- 6.1 RPC Information (Informations RPC)
- 6.2 NLM Procedures (Procédures NLM)
- 6.3 Implementation issues (Questions d'implémentation)
- 7. Appendix III: Bibliography (Annexe III : Bibliographie)
- 8. Security Considerations (Considérations de sécurité)
- 9. Acknowledgements (Remerciements)
- 10. Authors' Addresses (Adresses des auteurs)
Ressources associées (Related Resources)
- RFC officiel : RFC 1813
- DataTracker : RFC 1813 on IETF
1. Introduction
Le protocole NFS (NFS Protocol) de Sun fournit un accès distant transparent aux systèmes de fichiers partagés sur les réseaux. Le protocole NFS est conçu pour être indépendant de la machine, du système d'exploitation, de l'architecture réseau et du protocole de transport. Cette indépendance est obtenue grâce à l'utilisation de primitives d'appel de procédure distante (Remote Procedure Call, RPC) construites au-dessus d'une représentation de données externe (eXternal Data Representation, XDR). Des implémentations du protocole NFS version 2 existent pour une variété de machines, des ordinateurs personnels aux superordinateurs. La version initiale du protocole NFS est spécifiée dans la spécification du protocole Network File System [RFC1094]. Une description de l'implémentation initiale se trouve dans [Sandberg].
Le protocole MOUNT de support effectue les fonctions spécifiques au système d'exploitation qui permettent aux clients d'attacher des arborescences de répertoires distants à un point du système de fichiers local. Le processus de montage permet également au serveur d'accorder des privilèges d'accès distant à un ensemble restreint de clients via le contrôle d'exportation.
Le gestionnaire de verrous (Lock Manager) fournit un support pour le verrouillage de fichiers lorsqu'il est utilisé dans l'environnement NFS. Le protocole Network Lock Manager (NLM) isole les aspects intrinsèquement avec état du verrouillage de fichiers dans un protocole séparé.
Une description complète des protocoles ci-dessus et de leur implémentation se trouve dans [X/OpenNFS].
Le but de ce document est de:
-
Spécifier le protocole NFS version 3.
-
Décrire la sémantique du protocole par annotation et description de l'implémentation prévue.
-
Spécifier le protocole MOUNT version 3.
-
Décrire brièvement les changements entre le protocole NLM version 3 et le protocole NLM version 4.
Le texte normatif est la description des procédures RPC et des arguments et résultats, qui définit le protocole sur le fil (over-the-wire protocol) et la sémantique de ces procédures. Le matériel décrivant la pratique d'implémentation aide à comprendre la spécification du protocole et décrit certains problèmes d'implémentation possibles et leurs solutions. Il n'est pas possible de décrire toutes les implémentations, et l'implémentation du système d'exploitation UNIX du protocole NFS version 3 est le plus souvent utilisée pour fournir des exemples. Compte tenu de cela, la discussion sur l'implémentation n'a pas l'autorité de la description du protocole sur le fil lui-même.
1.1 Portée du protocole NFS version 3 (Scope of the NFS version 3 protocol)
Cette révision du protocole NFS répond à de nouvelles exigences. Le besoin de prendre en charge des fichiers et des systèmes de fichiers plus volumineux a conduit à des extensions permettant des tailles et des décalages de fichiers de 64 bits. La révision améliore la sécurité en ajoutant la prise en charge d'une vérification d'accès effectuée sur le serveur. Les modifications de performance sont de trois types:
-
Le nombre de paquets sur le fil pour un ensemble donné d'opérations de fichiers est réduit en renvoyant les attributs de fichiers à chaque opération, diminuant ainsi le nombre d'appels pour obtenir les attributs modifiés.
-
Le goulot d'étranglement du débit d'écriture causé par la définition synchrone de l'écriture dans le protocole NFS version 2 a été résolu en ajoutant la prise en charge pour que le serveur NFS puisse effectuer des écritures non sécurisées (unsafe writes). Les écritures non sécurisées sont des écritures qui n'ont pas été validées sur un stockage stable avant le retour de l'opération. Cette spécification définit une méthode pour valider ces écritures non sécurisées sur un stockage stable de manière fiable.
-
Les limitations sur les tailles de transfert ont été assouplies.
La capacité de prendre en charge plusieurs versions d'un protocole dans RPC permettra aux implémenteurs du protocole NFS version 3 de définir des clients et des serveurs offrant une compatibilité ascendante avec la base installée existante d'implémentations du protocole NFS version 2.
Les extensions décrites ici représentent une évolution du protocole NFS existant et la plupart des caractéristiques de conception du protocole NFS décrites dans [Sandberg] persistent. Voir Changements par rapport au protocole NFS version 2 à la page 11 pour un résumé plus détaillé des modifications introduites par cette révision.
1.2 Termes utiles (Useful terms)
Dans cette spécification, un "serveur (server)" est une machine qui fournit des ressources au réseau; un "client" est une machine qui accède aux ressources via le réseau; un "utilisateur (user)" est une personne connectée à un client; une "application" est un programme qui s'exécute sur un client.
1.3 Appel de procédure distante (Remote Procedure Call)
La spécification Sun Remote Procedure Call fournit une interface orientée procédure vers les services distants. Chaque serveur fournit un programme, qui est un ensemble de procédures. Le service NFS est l'un de ces programmes. La combinaison de l'adresse de l'hôte, du numéro de programme, du numéro de version et du numéro de procédure spécifie une procédure de service distant. Les serveurs peuvent prendre en charge plusieurs versions d'un programme en utilisant différents numéros de version de protocole.
Le protocole NFS a été conçu pour ne nécessiter aucun niveau spécifique de fiabilité de ses niveaux inférieurs afin qu'il puisse potentiellement être utilisé sur de nombreux protocoles de transport sous-jacents. Le service NFS est basé sur RPC qui fournit l'abstraction au-dessus des protocoles réseau et de transport de niveau inférieur.
Le reste de ce document suppose que l'environnement NFS est implémenté au-dessus de Sun RPC, qui est spécifié dans [RFC1057]. Une discussion complète se trouve dans [Corbin].
1.4 Représentation de données externe (External Data Representation)
La spécification de représentation de données externe (eXternal Data Representation, XDR) fournit un moyen standard de représenter un ensemble de types de données sur un réseau. Cela résout le problème des différents ordres d'octets, alignements de structure et représentation de types de données sur différentes machines communicantes.
Dans ce document, le langage de description de données RPC (RPC Data Description Language) est utilisé pour spécifier les paramètres et résultats au format XDR pour chacune des procédures de service RPC qu'un serveur NFS fournit. Le langage de description de données RPC est similaire aux déclarations dans le langage de programmation C. Quelques nouvelles constructions ont été ajoutées. La notation:
string name[SIZE];
string data<DSIZE>;
définit name, qui est un bloc de taille fixe de SIZE octets, et data, qui est un bloc de taille variable allant jusqu'à DSIZE octets. Cette notation indique des tableaux de longueur fixe et des tableaux avec un nombre variable d'éléments jusqu'à un maximum fixe. Une définition de longueur variable sans taille spécifiée signifie qu'il n'y a pas de taille maximale pour le champ.
La définition d'union discriminée:
union example switch (enum status) {
case OK:
struct {
filename file1;
filename file2;
integer count;
}
case ERROR:
struct {
errstat error;
integer errno;
}
default:
void;
}
définit une structure où la première chose sur le réseau est un type d'énumération appelé status. Si la valeur de status est OK, la chose suivante sur le réseau sera la structure contenant file1, file2 et count. Sinon, si la valeur de status est ERROR, la chose suivante sur le réseau sera une structure contenant error et errno. Si la valeur de status n'est ni OK ni ERROR, alors il n'y a plus de données dans la structure.
Le type XDR hyper est une quantité de 8 octets (64 bits). Il est utilisé de la même manière que le type entier. Par exemple:
hyper foo;
unsigned hyper bar;
foo est une valeur signée de 8 octets, tandis que bar est une valeur non signée de 8 octets.
Bien que des compilateurs RPC/XDR existent pour générer des stubs clients et serveurs à partir d'une entrée de langage de description de données RPC, les implémentations NFS ne nécessitent pas leur utilisation. Tout logiciel qui fournit un encodage et un décodage équivalents à l'ordre réseau canonique des données définies par XDR peut être utilisé pour interopérer avec d'autres implémentations NFS.
XDR est décrit dans [RFC1014].
1.5 Authentification et vérification des permissions (Authentication and Permission Checking)
Le protocole RPC inclut un emplacement pour les paramètres d'authentification à chaque appel. Le contenu des paramètres d'authentification est déterminé par le type d'authentification utilisé par le serveur et le client. Un serveur peut prendre en charge plusieurs saveurs d'authentification différentes à la fois. La saveur AUTH_NONE fournit une authentification nulle, c'est-à-dire qu'aucune information d'authentification n'est transmise. La saveur AUTH_UNIX fournit l'ID utilisateur, l'ID de groupe et les groupes de style UNIX à chaque appel. La saveur AUTH_DES fournit des paramètres d'authentification chiffrés DES basés sur un nom à l'échelle du réseau, avec des clés de session échangées via un schéma de clé publique. La saveur AUTH_KERB fournit des paramètres d'authentification chiffrés DES basés sur un nom à l'échelle du réseau avec des clés de session échangées via des clés secrètes Kerberos.
Le serveur NFS vérifie les permissions en prenant les informations d'identification des informations d'authentification RPC dans chaque demande distante. Par exemple, en utilisant la saveur d'authentification AUTH_UNIX, le serveur obtient l'ID utilisateur effectif, l'ID de groupe effectif et les groupes de l'utilisateur à chaque appel, et les utilise pour vérifier l'accès. L'utilisation des ID utilisateur et des ID de groupe implique que le client et le serveur partagent la même liste d'ID ou effectuent un mappage local des ID utilisateur et de groupe. Les serveurs et les clients doivent s'entendre sur le mappage de l'utilisateur à l'uid et du groupe au gid, pour les sites qui n'implémentent pas un espace d'ID utilisateur et d'ID de groupe cohérent. En pratique, un tel mappage est généralement effectué sur le serveur, selon un schéma de mappage statique ou un mappage établi par l'utilisateur depuis un client au moment du montage.
Le style d'authentification AUTH_DES et AUTH_KERB est basé sur un nom à l'échelle du réseau. Il offre une sécurité accrue grâce à l'utilisation du chiffrement DES et des clés publiques dans le cas d'AUTH_DES, et du chiffrement DES et des clés secrètes Kerberos (et des tickets) dans le cas d'AUTH_KERB. Encore une fois, le serveur et le client doivent s'entendre sur l'identité d'un nom particulier sur le réseau, mais le mappage nom-identité est plus indépendant du système d'exploitation que le mappage uid et gid dans AUTH_UNIX. De plus, comme les paramètres d'authentification sont chiffrés, un utilisateur malveillant doit connaître le mot de passe réseau ou la clé privée d'un autre utilisateur pour se faire passer pour cet utilisateur. De même, le vérificateur renvoyé par le serveur est également chiffré, de sorte que se faire passer pour un serveur nécessite de connaître un mot de passe réseau.
La procédure NULL ne nécessite généralement aucune authentification.
1.6 Philosophie (Philosophy)
Cette spécification définit le protocole NFS version 3, c'est-à-dire le protocole sur le fil par lequel un client accède à un serveur. Le protocole fournit une interface bien définie aux ressources de fichiers d'un serveur. Un client ou un serveur implémente le protocole et fournit un mappage de la sémantique et des actions du système de fichiers local à celles définies dans le protocole NFS version 3. Les implémentations peuvent différer à des degrés variables, selon la mesure dans laquelle un environnement donné peut prendre en charge toutes les opérations et la sémantique définies dans le protocole NFS version 3. Bien que des implémentations existent et soient utilisées pour illustrer divers aspects du protocole NFS version 3, la spécification du protocole elle-même est la description finale de la façon dont les clients accèdent aux ressources du serveur.
Étant donné que le protocole NFS version 3 est conçu pour être indépendant du système d'exploitation, il ne correspond pas nécessairement à la sémantique d'un système existant. Les implémentations de serveur sont censées faire de leur mieux pour prendre en charge le protocole. Si un serveur ne peut pas prendre en charge une procédure de protocole particulière, il peut renvoyer l'erreur NFS3ERR_NOTSUP, indiquant que l'opération n'est pas prise en charge. Par exemple, de nombreux systèmes d'exploitation ne prennent pas en charge la notion de lien dur. Un serveur qui ne peut pas prendre en charge les liens durs devrait renvoyer NFS3ERR_NOTSUP en réponse à une demande LINK. FSINFO décrit les procédures les plus couramment non prises en charge dans la carte de bits des propriétés. Alternativement, un serveur peut ne pas prendre en charge nativement une opération donnée, mais peut l'émuler dans l'implémentation du protocole NFS version 3 pour fournir une fonctionnalité accrue.
Dans certains cas, un serveur peut prendre en charge la plupart de la sémantique décrite par le protocole mais pas toute. Par exemple, le champ ctime dans la structure fattr donne le moment où les attributs d'un fichier ont été modifiés pour la dernière fois. De nombreux systèmes ne conservent pas cette information. Dans ce cas, plutôt que de ne pas prendre en charge l'opération GETATTR, un serveur pourrait la simuler en renvoyant l'heure de dernière modification à la place de ctime. Les serveurs doivent être prudents lors de la simulation d'informations d'attribut en raison des effets secondaires possibles sur les clients. Par exemple, de nombreux clients utilisent les temps de modification de fichiers comme base pour leur schéma de cohérence de cache.
Les serveurs NFS sont stupides et les clients NFS sont intelligents. Ce sont les clients qui effectuent le travail requis pour convertir l'accès aux fichiers généralisé que les serveurs fournissent en une méthode d'accès aux fichiers utile pour les applications et les utilisateurs. Dans l'exemple LINK donné ci-dessus, un client UNIX qui a reçu une erreur NFS3ERR_NOTSUP d'un serveur effectuerait la récupération nécessaire pour faire apparaître à l'application que la demande de lien a réussi ou renvoyer une erreur raisonnable. En général, c'est au client qu'incombe la récupération.
Le protocole NFS version 3 suppose une implémentation de serveur sans état. Sans état signifie que le serveur n'a pas besoin de maintenir l'état de l'un de ses clients pour fonctionner correctement. Les serveurs sans état ont un avantage distinct sur les serveurs avec état en cas de panne. Avec les serveurs sans état, un client n'a qu'à réessayer une demande jusqu'à ce que le serveur réponde; le client n'a même pas besoin de savoir que le serveur s'est planté. Voir commentaires supplémentaires dans Cache de demandes en double à la page 99.
Pour être utile, un serveur conserve un état non volatil: les données stockées dans le système de fichiers. Les hypothèses de conception dans le protocole NFS version 3 concernant le vidage des données modifiées vers un stockage stable réduisent le nombre de modes de défaillance dans lesquels une perte de données peut se produire. De cette façon, les implémentations du protocole NFS version 3 peuvent tolérer les défaillances transitoires, y compris les défaillances transitoires du réseau. En général, les implémentations de serveur du protocole NFS version 3 ne peuvent pas tolérer une défaillance non transitoire du stockage stable lui-même. Cependant, il existe des implémentations tolérantes aux pannes qui tentent de résoudre de tels problèmes.
Cela ne signifie pas qu'un serveur de protocole NFS version 3 ne peut pas maintenir un état non critique. Dans de nombreux cas, les serveurs maintiendront un état (cache) sur les opérations précédentes pour augmenter les performances. Par exemple, une demande de lecture (READ) client pourrait déclencher une lecture anticipée du bloc suivant du fichier dans le cache de données du serveur en anticipation que le client effectue une lecture séquentielle et que la prochaine demande de lecture (READ) client sera satisfaite à partir du cache de données du serveur au lieu du disque. La lecture anticipée sur le serveur augmente les performances en chevauchant les E/S disque du serveur avec les demandes client. Le point important ici est que le bloc de lecture anticipée n'est pas nécessaire pour un comportement correct du serveur. Si le serveur plante et perd son cache mémoire de tampons de lecture, la récupération est simple au redémarrage - les clients continueront les opérations de lecture en récupérant les données du disque du serveur.
La plupart des opérations de modification de données dans le protocole NFS sont synchrones. C'est-à-dire que lorsqu'une procédure de modification de données revient au client, le client peut supposer que l'opération est terminée et que toutes les données modifiées associées à la demande sont maintenant sur un stockage stable. Par exemple, une demande d'écriture (WRITE) client synchrone peut amener le serveur à mettre à jour des blocs de données, des blocs d'informations de système de fichiers et des informations d'attributs de fichiers - ces dernières informations sont généralement appelées métadonnées (metadata). Lorsque l'opération WRITE est terminée, le client peut supposer que les données écrites sont sûres et les rejeter. C'est une partie très importante de la nature sans état du serveur. Si le serveur n'avait pas vidé les données sales vers un stockage stable avant de revenir au client, le client n'aurait aucun moyen de savoir quand il est sûr de rejeter les données modifiées. Les procédures suivantes de modification de données sont synchrones: WRITE (avec indicateur stable défini sur FILE_SYNC), CREATE, MKDIR, SYMLINK, MKNOD, REMOVE, RMDIR, RENAME, LINK et COMMIT.
Le protocole NFS version 3 introduit des écritures asynchrones sûres sur le serveur, lorsque la procédure WRITE est utilisée conjointement avec la procédure COMMIT. La procédure COMMIT fournit un moyen pour le client de vider les données des demandes d'écriture (WRITE) asynchrones précédentes sur le serveur vers un stockage stable et de détecter s'il est nécessaire de retransmettre les données. Voir les descriptions de procédure de WRITE à la page 49 et COMMIT à la page 92.
La procédure LOOKUP est utilisée par le client pour parcourir les noms de fichiers à plusieurs composants (chemins d'accès). Chaque appel à LOOKUP est utilisé pour résoudre un segment d'un chemin d'accès. Il y a deux raisons pour restreindre LOOKUP à un seul segment: il est difficile de standardiser un format commun pour les noms de fichiers hiérarchiques et le client et le serveur peuvent avoir différents mappages de chemins d'accès vers des systèmes de fichiers. Cela impliquerait que soit le client doit casser le nom de chemin aux points d'attachement du système de fichiers, soit le serveur doit connaître les points d'attachement du système de fichiers du client. Dans les implémentations du protocole NFS version 3, c'est le client qui construit l'espace de noms de fichiers hiérarchique en utilisant des montages pour construire une hiérarchie. Les utilitaires de support, tels que l'Automounter, fournissent un moyen de gérer une image partagée et cohérente de l'espace de noms de fichiers tout en étant toujours piloté par le processus de montage du client.
Les clients peuvent effectuer une mise en cache de manière variée. La pratique générale avec le protocole NFS version 2 était d'implémenter un mécanisme de cohérence de cache client-serveur basé sur le temps. On s'attend à ce que les implémentations du protocole NFS version 3 utilisent un mécanisme similaire. Le protocole NFS version 3 dispose d'un certain support explicite, sous forme d'informations d'attributs supplémentaires pour éliminer les vérifications d'attributs explicites. Cependant, la mise en cache n'est pas requise, et aucune politique de mise en cache n'est définie par le protocole. Ni le protocole NFS version 2 ni le protocole NFS version 3 ne fournissent un moyen de maintenir une cohérence stricte client-serveur (et, par implication, une cohérence entre les caches clients).
1.7 Changements par rapport au protocole NFS version 2 (Changes from the NFS Version 2 Protocol)
Les procédures ROOT et WRITECACHE ont été supprimées. Une procédure MKNOD a été définie pour permettre la création de fichiers spéciaux, éliminant la surcharge de CREATE. La mise en cache sur le client n'est ni définie ni dictée par le protocole NFS version 3, mais des informations et des conseils supplémentaires ont été ajoutés au protocole pour permettre aux clients qui implémentent la mise en cache de gérer leurs caches plus efficacement. Les procédures qui affectent les attributs d'un fichier ou d'un répertoire peuvent désormais renvoyer les nouveaux attributs après la fin de l'opération pour optimiser un GETATTR suivant utilisé pour valider les caches d'attributs. De plus, les opérations qui modifient le répertoire dans lequel réside l'objet cible renvoient les anciens et nouveaux attributs du répertoire pour permettre aux clients d'implémenter des procédures d'invalidation de cache plus intelligentes. La procédure ACCESS fournit une vérification des permissions d'accès sur le serveur, la procédure FSSTAT renvoie des informations dynamiques sur un système de fichiers, la procédure FSINFO renvoie des informations statiques sur un système de fichiers et un serveur, la procédure READDIRPLUS renvoie des handles de fichiers et des attributs en plus des entrées de répertoire, et la procédure PATHCONF renvoie des informations POSIX pathconf sur un fichier.
Voici une liste des changements importants entre le protocole NFS version 2 et le protocole NFS version 3.
Taille du handle de fichier (File handle size)
Le handle de fichier a été augmenté d'un tableau fixe de 32 octets à un tableau de longueur variable de 64 octets maximum. Cela répond à certaines exigences connues pour une taille de handle de fichier légèrement plus grande. Le handle de fichier a été converti de longueur fixe à longueur variable pour réduire les exigences de stockage local et de bande passante réseau pour les systèmes qui n'utilisent pas les 64 octets complets de longueur.
Tailles de données maximales (Maximum data sizes)
La taille maximale d'un transfert de données utilisé dans les procédures READ et WRITE est maintenant définie par les valeurs de la structure de retour FSINFO. De plus, les tailles de transfert préférées sont renvoyées par FSINFO. Le protocole n'impose aucune limite artificielle sur les tailles de transfert maximales.
Les noms de fichiers et les chemins d'accès sont désormais spécifiés comme des chaînes de longueur variable. Les restrictions de longueur réelles sont déterminées par les implémentations client et serveur de manière appropriée. Le protocole n'impose aucune limite artificielle sur la longueur. L'erreur NFS3ERR_NAMETOOLONG est fournie pour permettre au serveur de renvoyer une indication au client qu'il a reçu un chemin d'accès trop long pour qu'il puisse le gérer.
Retour d'erreur (Error return)
Les retours d'erreur renvoient maintenant des données dans certains cas (par exemple, des attributs). nfsstat3 définit maintenant l'ensemble complet des erreurs qui peuvent être renvoyées par un serveur. Aucune autre valeur n'est autorisée.
Type de fichier (File type)
Le type de fichier inclut maintenant NF3CHR et NF3BLK pour les fichiers spéciaux. Les attributs de ces types incluent des sous-champs pour les numéros de périphérique majeurs et mineurs UNIX. NF3SOCK et NF3FIFO sont maintenant définis pour les sockets et les fifos dans le système de fichiers.
Attributs de fichier (File attributes)
Le champ blocksize (la taille en octets d'un bloc dans le fichier) a été supprimé. Le champ mode ne contient plus d'informations sur le type de fichier. Les champs size et fileid ont été élargis à des entiers non signés de huit octets à partir d'entiers de quatre octets. Les informations sur les périphériques majeurs et mineurs sont maintenant présentées dans une structure distincte. Le nom du champ blocks a été changé en used et contient maintenant le nombre total d'octets utilisés par le fichier. C'est également un entier non signé de huit octets.
Définir les attributs de fichier (Set file attributes)
Dans le protocole NFS version 2, les attributs définissables étaient représentés par un sous-ensemble de la structure des attributs de fichier; le client indiquait quels attributs ne devaient pas être modifiés en définissant le champ correspondant à -1, surchargeant certains champs non signés. La structure de définition des attributs de fichier utilise maintenant une union discriminée pour chaque champ afin d'indiquer si et comment définir ce champ. Les champs atime et mtime peuvent être définis soit sur l'heure actuelle du serveur, soit sur une heure fournie par le client.
LOOKUP
La structure de retour LOOKUP inclut maintenant les attributs du répertoire recherché.
ACCESS
Une procédure ACCESS a été ajoutée pour permettre une vérification explicite des permissions sur le fil. Cela résout des problèmes connus avec la fonctionnalité de mappage d'ID de superutilisateur dans de nombreuses implémentations de serveur (où, en raison du mappage de l'utilisateur root, des erreurs de permission refusée inattendues pouvaient se produire lors de la lecture ou de l'écriture dans un fichier). Cela supprime également l'hypothèse qui a été faite dans le protocole NFS version 2 selon laquelle l'accès aux fichiers était basé uniquement sur les bits de mode de style UNIX.
READ
La structure de réponse inclut un booléen qui est TRUE si la fin du fichier a été rencontrée pendant la lecture (READ). Cela permet au client de détecter correctement la fin du fichier.
WRITE
Les champs beginoffset et totalcount ont été supprimés des arguments WRITE. La réponse inclut maintenant un compteur afin que le serveur puisse écrire moins que la quantité de données demandée, si nécessaire. Un indicateur a été ajouté aux arguments pour indiquer au serveur le niveau de synchronisation de cache requis par le client.
CREATE
Un indicateur exclusif et un vérificateur de création ont été ajoutés pour la création exclusive de fichiers réguliers.
MKNOD
Cette procédure a été ajoutée pour prendre en charge la création de fichiers spéciaux. Cela évite la surcharge de CREATE comme cela a été fait dans certaines implémentations du protocole NFS version 2.
READDIR
Les arguments READDIR incluent maintenant un vérificateur pour permettre au serveur de valider le cookie. Le cookie est maintenant un entier non signé de 64 bits au lieu du tableau de 4 octets utilisé dans le protocole NFS version 2. Cela aidera à réduire les problèmes d'interopérabilité.
READDIRPLUS
Cette procédure a été ajoutée pour renvoyer des handles de fichiers et des attributs dans une liste de répertoires étendue.
FSINFO
FSINFO a été ajouté pour fournir des informations non volatiles sur un système de fichiers. La réponse inclut la taille de transfert de lecture préférée et maximale, la taille de transfert d'écriture préférée et maximale, et des indicateurs indiquant si les liens ou les liens symboliques sont pris en charge. Sont également renvoyés la taille de transfert préférée pour les réponses de procédure READDIR, la granularité temporelle du serveur, et si les heures peuvent être définies dans une demande SETATTR.
FSSTAT
FSSTAT a été ajouté pour fournir des informations volatiles sur un système de fichiers, pour une utilisation par des utilitaires tels que la commande df du système Unix. La réponse inclut la taille totale et l'espace libre dans le système de fichiers spécifié en octets, le nombre total de fichiers et le nombre d'emplacements de fichiers libres dans le système de fichiers, et une estimation du temps entre les modifications du système de fichiers (pour une utilisation dans les algorithmes de vérification de cohérence de cache).
COMMIT
La procédure COMMIT fournit le mécanisme de synchronisation à utiliser avec les opérations WRITE asynchrones.
2. Informations RPC (RPC Information)
2.1 Authentification (Authentication)
Le service NFS utilise AUTH_NONE dans la procédure NULL. AUTH_UNIX, AUTH_DES ou AUTH_KERB sont utilisés pour toutes les autres procédures. D'autres types d'authentification pourront être pris en charge à l'avenir.
2.2 Constantes (Constants)
Voici les constantes RPC nécessaires pour appeler le service NFS Version 3. Elles sont données en décimal.
PROGRAM 100003
VERSION 3
2.3 Adresse de transport (Transport address)
Le protocole NFS est normalement pris en charge sur les protocoles TCP et UDP. Il utilise le port 2049, le même que le protocole NFS version 2.
2.4 Tailles (Sizes)
Voici les tailles, en octets décimaux, des différentes structures XDR utilisées dans le protocole NFS version 3 :
NFS3_FHSIZE 64
- La taille maximale en octets du descripteur de fichier opaque.
NFS3_COOKIEVERFSIZE 8
- La taille en octets du vérificateur de cookie opaque passé par READDIR et READDIRPLUS.
NFS3_CREATEVERFSIZE 8
- La taille en octets du vérificateur opaque utilisé pour CREATE exclusif.
NFS3_WRITEVERFSIZE 8
- La taille en octets du vérificateur opaque utilisé pour WRITE asynchrone.
2.5 Types de données de base (Basic Data Types)
Les définitions XDR suivantes sont des définitions de base utilisées dans d'autres structures.
uint64
typedef unsigned hyper uint64;
int64
typedef hyper int64;
uint32
typedef unsigned long uint32;
int32
typedef long int32;
filename3
typedef string filename3<>;
nfspath3
typedef string nfspath3<>;
fileid3
typedef uint64 fileid3;
cookie3
typedef uint64 cookie3;
cookieverf3
typedef opaque cookieverf3[NFS3_COOKIEVERFSIZE];
createverf3
typedef opaque createverf3[NFS3_CREATEVERFSIZE];
writeverf3
typedef opaque writeverf3[NFS3_WRITEVERFSIZE];
uid3
typedef uint32 uid3;
gid3
typedef uint32 gid3;
size3
typedef uint64 size3;
offset3
typedef uint64 offset3;
mode3
typedef uint32 mode3;
count3
typedef uint32 count3;
nfsstat3
enum nfsstat3 {
NFS3_OK = 0,
NFS3ERR_PERM = 1,
NFS3ERR_NOENT = 2,
NFS3ERR_IO = 5,
NFS3ERR_NXIO = 6,
NFS3ERR_ACCES = 13,
NFS3ERR_EXIST = 17,
NFS3ERR_XDEV = 18,
NFS3ERR_NODEV = 19,
NFS3ERR_NOTDIR = 20,
NFS3ERR_ISDIR = 21,
NFS3ERR_INVAL = 22,
NFS3ERR_FBIG = 27,
NFS3ERR_NOSPC = 28,
NFS3ERR_ROFS = 30,
NFS3ERR_MLINK = 31,
NFS3ERR_NAMETOOLONG = 63,
NFS3ERR_NOTEMPTY = 66,
NFS3ERR_DQUOT = 69,
NFS3ERR_STALE = 70,
NFS3ERR_REMOTE = 71,
NFS3ERR_BADHANDLE = 10001,
NFS3ERR_NOT_SYNC = 10002,
NFS3ERR_BAD_COOKIE = 10003,
NFS3ERR_NOTSUPP = 10004,
NFS3ERR_TOOSMALL = 10005,
NFS3ERR_SERVERFAULT = 10006,
NFS3ERR_BADTYPE = 10007,
NFS3ERR_JUKEBOX = 10008
};
Le type nfsstat3 est retourné avec les résultats de chaque procédure, sauf pour la procédure NULL. Une valeur de NFS3_OK indique que l'appel s'est terminé avec succès. Toute autre valeur indique qu'une erreur s'est produite lors de l'appel, identifiée par le code d'erreur. Notez que l'encodage numérique précis doit être suivi. Aucune autre valeur ne peut être retournée par un serveur. Les serveurs sont censés faire de leur mieux pour mapper les conditions d'erreur à l'ensemble des codes d'erreur définis. De plus, aucune priorité d'erreur n'est spécifiée par cette spécification. Les priorités d'erreur déterminent la valeur d'erreur qui doit être retournée lorsque plusieurs erreurs s'appliquent dans une situation donnée. La priorité d'erreur sera déterminée par l'implémentation individuelle du serveur. Si le client nécessite des priorités d'erreur spécifiques, il doit vérifier lui-même les erreurs spécifiques.
2.6 Numéros d'erreur définis (Defined Error Numbers)
Une description de chaque erreur définie suit :
NFS3_OK
- Indique que l'appel s'est terminé avec succès.
NFS3ERR_PERM
- Pas propriétaire. L'opération n'a pas été autorisée car l'appelant n'est pas un utilisateur privilégié (root) ou n'est pas le propriétaire de la cible de l'opération.
NFS3ERR_NOENT
- Fichier ou répertoire inexistant. Le nom de fichier ou de répertoire spécifié n'existe pas.
NFS3ERR_IO
- Erreur d'E/S. Une erreur matérielle (par exemple, une erreur disque) s'est produite lors du traitement de l'opération demandée.
NFS3ERR_NXIO
- Erreur d'E/S. Aucun périphérique ou adresse de ce type.
NFS3ERR_ACCES
- Permission refusée. L'appelant n'a pas la permission correcte pour effectuer l'opération demandée. Comparez ceci avec NFS3ERR_PERM, qui se limite aux échecs de permission du propriétaire ou de l'utilisateur privilégié.
NFS3ERR_EXIST
- Le fichier existe. Le fichier spécifié existe déjà.
NFS3ERR_XDEV
- Tentative de créer un lien physique inter-périphériques.
NFS3ERR_NODEV
- Aucun périphérique de ce type.
NFS3ERR_NOTDIR
- Pas un répertoire. L'appelant a spécifié un non-répertoire dans une opération de répertoire.
NFS3ERR_ISDIR
- Est un répertoire. L'appelant a spécifié un répertoire dans une opération non-répertoire.
NFS3ERR_INVAL
- Argument invalide ou argument non pris en charge pour une opération. Deux exemples sont la tentative d'un READLINK sur un objet autre qu'un lien symbolique ou la tentative d'un SETATTR d'un champ temporel sur un serveur qui ne prend pas en charge cette opération.
NFS3ERR_FBIG
- Fichier trop volumineux. L'opération aurait causé la croissance d'un fichier au-delà de la limite du serveur.
NFS3ERR_NOSPC
- Aucun espace restant sur le périphérique. L'opération aurait causé le dépassement de sa limite par le système de fichiers du serveur.
NFS3ERR_ROFS
- Système de fichiers en lecture seule. Une opération de modification a été tentée sur un système de fichiers en lecture seule.
NFS3ERR_MLINK
- Trop de liens physiques.
NFS3ERR_NAMETOOLONG
- Le nom de fichier dans une opération était trop long.
NFS3ERR_NOTEMPTY
- Une tentative a été faite pour supprimer un répertoire qui n'était pas vide.
NFS3ERR_DQUOT
- Limite dure de ressource (quota) dépassée. La limite de ressource de l'utilisateur sur le serveur a été dépassée.
NFS3ERR_STALE
- Descripteur de fichier invalide. Le descripteur de fichier donné dans les arguments était invalide. Le fichier référencé par ce descripteur de fichier n'existe plus ou l'accès à celui-ci a été révoqué.
NFS3ERR_REMOTE
- Trop de niveaux de remote dans le chemin. Le descripteur de fichier donné dans les arguments référençait un fichier sur un système de fichiers non local sur le serveur.
NFS3ERR_BADHANDLE
- Descripteur de fichier NFS illégal. Le descripteur de fichier a échoué aux vérifications de cohérence interne.
NFS3ERR_NOT_SYNC
- Une incompatibilité de synchronisation de mise à jour a été détectée lors d'une opération SETATTR.
NFS3ERR_BAD_COOKIE
- Le cookie READDIR ou READDIRPLUS est périmé.
NFS3ERR_NOTSUPP
- L'opération n'est pas prise en charge.
NFS3ERR_TOOSMALL
- Le tampon ou la demande est trop petit.
NFS3ERR_SERVERFAULT
- Une erreur s'est produite sur le serveur qui ne correspond à aucune des valeurs d'erreur légales du protocole NFS version 3. Le client doit traduire cela en une erreur appropriée. Les clients UNIX peuvent choisir de traduire cela en EIO.
NFS3ERR_BADTYPE
- Une tentative a été faite pour créer un objet d'un type non pris en charge par le serveur.
NFS3ERR_JUKEBOX
- Le serveur a initié la demande, mais n'a pas pu la terminer dans un délai opportun. Le client doit attendre puis réessayer la demande avec un nouvel ID de transaction RPC. Par exemple, cette erreur doit être retournée par un serveur qui prend en charge le stockage hiérarchique et reçoit une demande de traitement d'un fichier qui a été migré. Dans ce cas, le serveur doit démarrer le processus d'immigration et répondre au client avec cette erreur.
ftype3
enum ftype3 {
NF3REG = 1,
NF3DIR = 2,
NF3BLK = 3,
NF3CHR = 4,
NF3LNK = 5,
NF3SOCK = 6,
NF3FIFO = 7
};
L'énumération ftype3 donne le type d'un fichier. Le type NF3REG est un fichier régulier, NF3DIR est un répertoire, NF3BLK est un fichier périphérique bloc spécial, NF3CHR est un fichier périphérique caractère spécial, NF3LNK est un lien symbolique, NF3SOCK est un socket et NF3FIFO est un tube nommé. Notez que l'encodage enum précis doit être suivi.
specdata3
struct specdata3 {
uint32 specdata1;
uint32 specdata2;
};
L'interprétation des deux mots dépend du type d'objet du système de fichiers. Pour un fichier spécial bloc (NF3BLK) ou caractère spécial (NF3CHR), specdata1 et specdata2 sont respectivement les numéros de périphérique majeur et mineur. (Il s'agit évidemment d'une interprétation spécifique à UNIX.) Pour tous les autres types de fichiers, ces deux éléments doivent être définis sur 0 ou les valeurs doivent être convenues entre le client et le serveur. Si le client et le serveur ne s'accordent pas sur les valeurs, le client doit traiter ces champs comme s'ils étaient définis sur 0. Ce champ de données est retourné dans le cadre de la structure fattr3 et est donc disponible dans toutes les réponses retournant des attributs. Puisque ces champs sont par ailleurs inutilisés pour les objets qui ne sont pas des périphériques, des informations hors bande peuvent être transmises du serveur au client. Cependant, encore une fois, le serveur et le client doivent s'accorder sur les valeurs transmises.
nfs_fh3
struct nfs_fh3 {
opaque data<NFS3_FHSIZE>;
};
Le nfs_fh3 est l'objet opaque de longueur variable retourné par le serveur lors des opérations LOOKUP, CREATE, SYMLINK, MKNOD, LINK ou READDIRPLUS, qui est utilisé par le client lors des opérations ultérieures pour référencer le fichier. Le descripteur de fichier contient toutes les informations dont le serveur a besoin pour distinguer un fichier individuel. Pour le client, le descripteur de fichier est opaque. Le client stocke les descripteurs de fichier pour une utilisation dans une demande ultérieure et peut comparer deux descripteurs de fichier du même serveur pour l'égalité en effectuant une comparaison octet par octet, mais ne peut pas interpréter autrement le contenu des descripteurs de fichier. Si deux descripteurs de fichier du même serveur sont égaux, ils doivent faire référence au même fichier, mais s'ils ne sont pas égaux, aucune conclusion ne peut être tirée. Les serveurs doivent essayer de maintenir une correspondance un-à-un entre les descripteurs de fichier et les fichiers, mais cela n'est pas requis. Les clients doivent utiliser les comparaisons de descripteurs de fichier uniquement pour améliorer les performances, pas pour un comportement correct.
Les serveurs peuvent révoquer l'accès fourni par un descripteur de fichier à tout moment. Si le descripteur de fichier transmis dans un appel fait référence à un objet du système de fichiers qui n'existe plus sur le serveur ou si l'accès pour ce descripteur de fichier a été révoqué, l'erreur NFS3ERR_STALE doit être retournée.
nfstime3
struct nfstime3 {
uint32 seconds;
uint32 nseconds;
};
La structure nfstime3 donne le nombre de secondes et de nanosecondes depuis minuit le 1er janvier 1970, heure moyenne de Greenwich. Elle est utilisée pour transmettre des informations de date et d'heure. Les heures associées aux fichiers sont toutes des heures du serveur, sauf dans le cas d'une opération SETATTR où le client peut explicitement définir l'heure du fichier. Un serveur convertit vers et depuis l'heure locale lors du traitement des valeurs de temps, en préservant autant de précision que possible. Si la précision des horodatages stockés pour un fichier est inférieure à celle définie par le protocole NFS version 3, une perte de précision peut se produire. Un protocole de maintenance du temps adjoint est recommandé pour réduire le décalage temporel entre le client et le serveur.
fattr3
struct fattr3 {
ftype3 type;
mode3 mode;
uint32 nlink;
uid3 uid;
gid3 gid;
size3 size;
size3 used;
specdata3 rdev;
uint64 fsid;
fileid3 fileid;
nfstime3 atime;
nfstime3 mtime;
nfstime3 ctime;
};
Cette structure définit les attributs d'un objet du système de fichiers. Elle est retournée par la plupart des opérations sur un objet ; dans le cas d'opérations qui affectent deux objets (par exemple, un MKDIR qui modifie les attributs du répertoire cible et définit de nouveaux attributs pour le répertoire nouvellement créé), les attributs des deux peuvent être retournés. Dans certains cas, les attributs sont retournés dans la structure wcc_data, qui est définie ci-dessous ; dans d'autres cas, les attributs sont retournés seuls. Les principaux changements par rapport au protocole NFS version 2 sont que de nombreux champs ont été élargis et que les informations de périphérique majeur/mineur sont maintenant présentées dans une structure distincte plutôt que d'être empaquetées dans un mot.
La structure fattr3 contient les attributs de base d'un fichier. Tous les serveurs doivent prendre en charge cet ensemble d'attributs même s'ils doivent simuler certains des champs. Type est le type du fichier. Mode sont les bits de mode de protection. Nlink est le nombre de liens physiques vers le fichier, c'est-à-dire le nombre de noms différents pour le même fichier. Uid est l'ID utilisateur du propriétaire du fichier. Gid est l'ID de groupe du groupe du fichier. Size est la taille du fichier en octets. Used est le nombre d'octets d'espace disque que le fichier utilise réellement (qui peut être inférieur à la taille car le fichier peut avoir des trous ou il peut être plus grand en raison de la fragmentation). Rdev décrit le fichier périphérique si le type de fichier est NF3CHR ou NF3BLK - voir specdata3 page 20. Fsid est l'identifiant du système de fichiers pour le système de fichiers. Fileid est un nombre qui identifie de manière unique le fichier dans son système de fichiers (sur UNIX, ce serait le inumber). Atime est l'heure à laquelle les données du fichier ont été accédées pour la dernière fois. Mtime est l'heure à laquelle les données du fichier ont été modifiées pour la dernière fois. Ctime est l'heure à laquelle les attributs du fichier ont été modifiés pour la dernière fois. L'écriture dans le fichier modifie le ctime en plus du mtime.
Les bits de mode sont définis comme suit :
0x00800 Définir l'ID utilisateur à l'exécution.
0x00400 Définir l'ID de groupe à l'exécution.
0x00200 Enregistrer le texte échangé (non défini dans POSIX).
0x00100 Permission de lecture pour le propriétaire.
0x00080 Permission d'écriture pour le propriétaire.
0x00040 Permission d'exécution pour le propriétaire sur un fichier. Ou permission de recherche pour le propriétaire dans un répertoire.
0x00020 Permission de lecture pour le groupe.
0x00010 Permission d'écriture pour le groupe.
0x00008 Permission d'exécution pour le groupe sur un fichier. Ou permission de recherche pour le groupe dans un répertoire.
0x00004 Permission de lecture pour les autres.
0x00002 Permission d'écriture pour les autres.
0x00001 Permission d'exécution pour les autres sur un fichier. Ou permission de recherche pour les autres dans un répertoire.
post_op_attr
union post_op_attr switch (bool attributes_follow) {
case TRUE:
fattr3 attributes;
case FALSE:
void;
};
Cette structure est utilisée pour retourner des attributs dans les opérations qui ne sont pas directement impliquées dans la manipulation des attributs. L'un des principes de cette révision du protocole NFS est de retourner la valeur réelle de l'opération indiquée et non une erreur d'une opération accessoire. La structure post_op_attr a été conçue pour permettre au serveur de se remettre des erreurs rencontrées lors de l'obtention des attributs.
Cela semble rendre le retour des attributs facultatif. Cependant, les implémenteurs de serveurs sont fortement encouragés à faire de leur mieux pour retourner les attributs dans la mesure du possible, même lors du retour d'une erreur.
wcc_attr
struct wcc_attr {
size3 size;
nfstime3 mtime;
nfstime3 ctime;
};
Il s'agit du sous-ensemble des attributs de pré-opération nécessaires pour mieux prendre en charge la sémantique de cohérence de cache faible. Size est la taille du fichier en octets de l'objet avant l'opération. Mtime est l'heure de la dernière modification de l'objet avant l'opération. Ctime est l'heure du dernier changement des attributs de l'objet avant l'opération. Voir la discussion dans wcc_attr page 24.
L'utilisation de mtime par les clients pour détecter les changements des objets du système de fichiers résidant sur un serveur dépend de la granularité de la base de temps sur le serveur.
pre_op_attr
union pre_op_attr switch (bool attributes_follow) {
case TRUE:
wcc_attr attributes;
case FALSE:
void;
};
wcc_data
struct wcc_data {
pre_op_attr before;
post_op_attr after;
};
Lorsqu'un client effectue une opération qui modifie l'état d'un fichier ou d'un répertoire sur le serveur, il ne peut pas déterminer immédiatement à partir des attributs de post-opération si l'opération qui vient d'être effectuée était la seule opération sur l'objet depuis la dernière fois que le client a reçu les attributs de l'objet. Ceci est important, car si une opération intermédiaire a modifié l'objet, le client devra invalider toutes les données mises en cache pour l'objet (sauf les données qu'il vient d'écrire).
Pour gérer cela, la notion de données de cohérence de cache faible ou wcc_data est introduite. Une structure wcc_data se compose de certains champs clés des attributs de l'objet avant l'opération, ainsi que des attributs de l'objet après l'opération. Ces informations permettent au client de gérer son cache plus précisément que dans les implémentations du protocole NFS version 2. Le terme cohérence de cache faible souligne le fait que ce mécanisme ne fournit pas la cohérence stricte serveur-client qu'un protocole de cohérence de cache fournirait.
Pour prendre en charge le modèle de cohérence de cache faible, le serveur devra être capable d'obtenir les attributs de pré-opération de l'objet, d'effectuer l'opération de modification prévue, puis d'obtenir les attributs de post-opération de manière atomique. S'il existe une fenêtre pour que l'objet soit modifié entre l'opération et l'une ou l'autre des opérations d'obtention d'attributs, alors le client ne pourra pas déterminer s'il était la seule entité à modifier l'objet. Certaines informations auront été perdues, affaiblissant ainsi les garanties de cohérence de cache faible.
post_op_fh3
union post_op_fh3 switch (bool handle_follows) {
case TRUE:
nfs_fh3 handle;
case FALSE:
void;
};
L'un des principes de cette révision du protocole NFS est de retourner la valeur réelle de l'opération indiquée et non une erreur d'une opération accessoire. La structure post_op_fh3 a été conçue pour permettre au serveur de se remettre des erreurs rencontrées lors de la construction d'un descripteur de fichier.
Il s'agit de la structure utilisée pour retourner un descripteur de fichier à partir des demandes CREATE, MKDIR, SYMLINK, MKNOD et READDIRPLUS. Dans chaque cas, le client peut obtenir le descripteur de fichier en émettant une demande LOOKUP après un retour réussi de l'une des opérations répertoriées. Le retour du descripteur de fichier est une optimisation afin que le client ne soit pas forcé d'émettre immédiatement une demande LOOKUP pour obtenir le descripteur de fichier.
sattr3
enum time_how {
DONT_CHANGE = 0,
SET_TO_SERVER_TIME = 1,
SET_TO_CLIENT_TIME = 2
};
union set_mode3 switch (bool set_it) {
case TRUE:
mode3 mode;
default:
void;
};
union set_uid3 switch (bool set_it) {
case TRUE:
uid3 uid;
default:
void;
};
union set_gid3 switch (bool set_it) {
case TRUE:
gid3 gid;
default:
void;
};
union set_size3 switch (bool set_it) {
case TRUE:
size3 size;
default:
void;
};
union set_atime switch (time_how set_it) {
case SET_TO_CLIENT_TIME:
nfstime3 atime;
default:
void;
};
union set_mtime switch (time_how set_it) {
case SET_TO_CLIENT_TIME:
nfstime3 mtime;
default:
void;
};
struct sattr3 {
set_mode3 mode;
set_uid3 uid;
set_gid3 gid;
set_size3 size;
set_atime atime;
set_mtime mtime;
};
La structure sattr3 contient les attributs de fichier qui peuvent être définis à partir du client. Les champs sont les mêmes que les champs de nom similaire dans la structure fattr3. Dans le protocole NFS version 3, les attributs définissables sont décrits par une structure contenant un ensemble d'unions discriminées. Chaque union indique si l'attribut correspondant doit être mis à jour et, le cas échéant, comment.
Deux formes d'unions discriminées sont utilisées. Pour définir le mode, l'uid, le gid ou la taille, l'union discriminée est commutée sur un booléen, set_it ; s'il est TRUE, une valeur du type approprié est alors encodée.
Pour définir atime ou mtime, l'union est commutée sur un type d'énumération, set_it. Si set_it a la valeur DONT_CHANGE, l'attribut correspondant est inchangé. S'il a la valeur SET_TO_SERVER_TIME, l'attribut correspondant est défini par le serveur à son heure locale ; aucune donnée n'est fournie par le client. Enfin, si set_it a la valeur SET_TO_CLIENT_TIME, l'attribut est défini sur l'heure transmise par le client dans une structure nfstime3. (Voir FSINFO page 86, qui traite de la question de la granularité temporelle).
diropargs3
struct diropargs3 {
nfs_fh3 dir;
filename3 name;
};
La structure diropargs3 est utilisée dans les opérations de répertoire. Le descripteur de fichier, dir, identifie le répertoire dans lequel manipuler ou accéder au fichier, name. Voir les commentaires supplémentaires dans Gestion des composants de nom de fichier page 101.