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.