Idée de base = pouvoir partager entre plusieurs clients et serveurs hétérogènes un même système de fichiers.
Une machine peut être à la fois client et serveur.
Un serveur NFS exporte ses directories pour qu'elles soient accessibles par des clients.
Si une directory est exportée, c'est tout le sous-arbre qui est exporté.
Liste des directories exportées dans /etc/exports.
Une station cliente sans disque (diskless) peut faire "comme si" elle avait un disque en montant des systèmes distants.
Une station avec un disque local aura une hierarchie en partie locale et distante.
Pour les programmes du client pas de
différence entre fichiers locaux ou distants.
Si deux clients ont monté la même directory, ils en partagent les fichiers.
simplicité de NFS.
clients et serveurs utilisant différents
OS et différentes machines.
Il est impératif de définir une bonne interface client/serveur.
Avantage d'une interface clairement définie : possibilité d'écrire de nouveaux clients et serveurs compatibles.
2 protocoles sont définis.
1 protocole pour le mounting et 1 protocole pour la directory et l' accès aux fichiers.
C envoie à S un chemin d'accès (le nom de la directory à monter) et demande la permission de monter la directory chez lui.
L'endroit où C va monter la directory n'est pas important pour S.
Si le chemin d'accès est correct et si la directory se trouve dans /etc/exports, S renvoie un file handle à C.
Le handle est composé :
Un client peut monter des directory sans intervention humaine.
Ces clients ont un fichier /etc/rc shell script qui contient les commandes de mount et lancé automatiquement au boot.
C'est le static mounting.
Les versions récentes de Sun Unix ont l' automounting :
Des directory distantes sont associées à des directories locales, mais elles ne sont pas montées, et leurs serveurs ne sont pas contactés au boot.
La première fois qu'un client accède à un fichier distant, les serveurs sont contactés. Le premier qui répond gagne.
Les clients envoient des messages pour manipuler des directories, lire et écrire des fichiers et leurs attributs (taille, date de modification, propriétaire, etc.).
Tous les appels systèmes sont pris en charge par NFS sauf OPEN et CLOSE.
OPEN et CLOSE ne sont pas utiles :
Un serveur NFS est stateless.
Fichier fermé verrous relachés.
NFS est stateless, on ne peut pas associer de verrous à l'ouverture d'un fichier.
Il faut un mécanisme externe à NFS pour gérer le verouillage.
NFS utilise quand même le système de protection Unix (bits rwx pour le owner, group et world).
MAIS : le serveur NFS croit toujours le client pour valider un accès.
Que faire si le client ment ?
Utilisation de la cryptographie pour valider les requêtes.
Problème : les données, elles, ne sont pas cryptées.
Les clés sont gérées par le NIS ( Network Information Service, ou yellow pages)
La couche VFS maintient une table pour chaque fichier ouvert.
Chaque entrée est un v-node (virtual i-node). On indique si le fichier est local ou distant.
Exemple : la séquence < MOUNT, OPEN, READ >.
Automatiquement, dès que le client a reçu les 8ko demandés, une nouvelle requête de 8ko est envoyée.
C'est le read ahead.
Tant que les données écrites sont < 8ko, elles sont accumulées localement.
Dès que le client a écrit 8ko, les 8ko sont envoyé au serveur.
Quand un fichier est fermé, ce qui reste à écrire est envoyé au serveur.
Utilisation du caching :
les clients ont 2 caches : attributs et données.
problèmes de cohérences.