Virtual File System

VFS est le résultat de la rencontre, en 1985, de deux systèmes de fichiers : UFS et NFS. Dans les années 1980, les réseaux prennent de l'importance. Sun développe différents produits orientés réseaux : une version du protocole RPC pour Unix, le protocole NIS pour centraliser les informations sur un réseau UNIX, et NFS, un système de fichiers distribué[2]. Le développement de NFS tente de répondre à une contrainte simple à énoncer : l'accès aux fichiers distants doit se réaliser de manière transparente pour les processus utilisateur, c'est-à-dire que ces processus ne doivent pas se soucier de savoir si ces fichiers sont locaux ou distants. Pour cela, NFS doit être capable de prendre en charge les mêmes appels système que le système de fichiers local (à l'époque on passe d'UFS à FFS). Sun choisit, avec le développement de VFS, de concevoir une couche d'abstraction capable de prendre en charge les appels système usuels (open, read, etc.) et de les transmettre à des couches inférieures chargées de manipuler les systèmes de fichiers concrets (NFS et UFS).

L'architecture de VFS est conçue pour répondre aux contraintes suivantes[3] :

• l'implémentation du système de fichiers est divisée en deux couches, l'une indépendante des systèmes de fichiers concrets, l'autre dépendante de ces systèmes ;
• l'architecture doit supporter les systèmes de fichiers UNIX et non UNIX, les systèmes de fichiers avec ou sans état ;
• elle doit supporter le côté serveur des systèmes de fichiers distants comme NFS ;
• les opérations doivent être atomiques pour éviter l'usage des verrous.

Dans la foulée, la couche logicielle qui gère UFS est adaptée par Sun pour fonctionner avec la couche basse de VFS[2]. Il apparaît rapidement que, même en l'absence de NFS, VFS est un système particulièrement efficace pour faire fonctionner différents systèmes de fichiers dans une arborescence unifiée. Sun développera rapidement une autre couche logicielle pour le système de fichiers FAT de MS-DOS.

À la même époque, System V intègre à sa version 3 (SVR3) un dispositif semblable nommé File System Switch (FSS). FSS est un système de fichiers virtuel, et en tant que tel donc capable de supporter plusieurs systèmes de fichiers concrets. Chaque système de fichiers concret possède une structure qui contient l'ensemble des opérations dépendantes de ce système. Un pointeur sur la structure adéquate est placé dans chaque inode (l'abstraction fondamentale utilisée par le système pour manipuler un fichier), de manière que les opérations soient accessibles de manière transparente[4].

Sun et AT&T unissent leurs efforts pour produire une synthèse et VFS et FSS. Cette synthèse, qui apparaît dans SVR4 en 1990, va rester remarquablement stable. L'architecture de VFS pour les systèmes Solaris est encore aujourd'hui très proche de celle de SVR4.

Pourtant, des évolutions ont été proposées pour améliorer l'extensibilité et la modularité de VFS[5] : celle de Rosenthal et celle de l'Université de Californie à Los Angeles (UCLA), par Heidemann et Popek. Les deux modèles ont en commun l'idée de diviser VFS en couches, mais leur approche est fondamentalement différente. Le prototype de Rosenthal consiste à empiler les couches d'abstractions les unes au-dessus des autres, de manière que la couche n-1 soit considérée comme le système de fichiers concret par la couche n, et s'adresse à la couche n-2 comme à un système de fichiers concret. Heidemann et Popek prennent au contraire le parti de diviser VFS en couches hétérogènes, chacune remplissant une fonction bien spécifique et fournissant des services déterminés à la couche supérieure (ce modèle est proche du modèle OSI, par exemple). Ce modèle est appelé modèle UCLA, en raison du lieu où il a été conçu. Nommage, stockage des données, chiffrement... sont quelques-unes des couches proposées par Heidemann. Le but du modèle UCLA est de permettre la réutilisation du code dans le développement de nouveaux systèmes de fichiers virtuels. Un exemple simple est celui du chiffrement : la couche peut-être intégrée ou non dans le système sans qu'il y ait à se soucier de recoder l'ensemble. De plus, le modèle UCLA ne limite pas les opérations sur un système de fichiers, ce qui permet une grande extensibilité.

En 1991, Heidemann implémente le modèle UCLA sur 4.4BSD. Le modèle est présent sur toutes les versions modernes de BSD, dont FreeBSD et Mac OS X.

Cette structure contient les informations fondamentales portant sur un système de fichiers monté :

• l'identifiant du périphérique qui contient le système ;
• la taille de bloc du système ;
• les numéros du premier inode du système de l'inode du répertoire où est monté le système ;
• un pointeur sur la structure file_system_type associée au système de fichiers (qui contient un pointeur qui permet de lire le superblock, le nom du système de fichiers, et si ce système de fichiers a besoin d'un périphérique) ;
• un pointeur sur des informations propres au système ;
• une structure super_operations qui contient des pointeurs sur les fonctions propres au superblock du système de fichiers concret.

Cette structure décrit de manière unique chaque fichier et répertoire du système de fichiers. Les inodes de VFS sont très semblables à ceux de ext2, et construits à partir des systèmes de fichiers sous-jacents. Les inodes les plus souvent utilisés sont contenus dans un cache.

On trouve dans cette structure :

• l'identifiant du périphérique qui contient le fichier ;
• la taille de bloc du fichier ;
• le numéro de l'inode ;
• les permissions d'accès ;
• les identifiants du propriétaire, groupe, etc. ;
• les informations de temps ;
• un compteur de références ;
• un marqueur de verrou ;
• un marqueur d'écriture ;
• des informations sur le système de fichiers ;
• une structure inode_operations (pour les opérations dépendantes du système de fichiers).

L'objet dentry (d-irectory entry) représente un chemin d'accès. C'est une structure créée à la volée lorsqu'un appel système utilise un chemin complet. Elle contient les informations suivantes :

• nom du fichier (avec son chemin) ;
• un pointeur sur l'inode associé ;
• un pointeur sur le dentry parent ;
• éventuellement des pointeurs sur les dentries enfants ;
• une structure dentry_operations (pour les opérations dépendantes du système de fichiers).

Ces dentries sont stockés par VFS dans un cache, ce qui permet d'accélérer la recherche de fichier.

Cette structure est la représentation d'un fichier en mémoire. Une telle structure est créée à chaque fois qu'un processus ouvre un fichier. Elle contient :

• le dentry associé au fichier ;
• le mode d'accès au fichier ;
• l'index de lecture ou d'écriture sur le fichier ;
• une structure file_operations (pour les opérations dépendantes du système de fichiers).

Les structures super_operations, inode_operations, dentry_operations et file_operations existent pour chaque système de fichiers concret considéré. Elles implémentent les opérations dépendantes du système de fichiers et constituent donc la couche logicielle dépendante de celui-ci, par opposition à la couche indépendante.

On effectue le montage d'un système de fichiers FAT avec la commande shell suivante :

#mount -t vfat /dev/hda1 /mnt/fatpartition

En interne, VFS va trouver la structure file_system_type associée à FAT et exécuter la fonction read_super(). Cette fonction fait partie de la couche dépendante du système de fichiers concret (en l'occurrence, FAT). Elle crée une structure superblock et lit sur le disque les informations nécessaires au remplissage de la structure ; elle fournit en particulier les fonctions dépendantes de FAT (dans super_operations).

La recherche d'un fichier, la lecture ou l'écriture se réalisent ensuite au moyen des opérations dépendantes du système de fichiers concret. Par exemple, pour la plupart des systèmes de fichiers concrets, l'objet inode n'existe pas en tant que structure de données sur le disque, mais la fonction read_inode permet à VFS de fonctionner comme si c'était le cas. Cette fonction lit les données sur le disque et remplit la structure inode de VFS.

Le système de fichiers /proc est un cas particulier qui illustre la puissance de VFS. Ce système de fichiers n'existe pas sur disque, mais est créé par le système afin de fournir une interface entre l'utilisateur et le noyau[7]. Ce système de fichiers est enregistré par VFS (il possède sa propre structure file_system_type). Les répertoires et fichiers sont simplement créés à la volée par la couche dépendante du système de fichiers concret ici fictif, à partir des informations du noyau.

• Système de fichiers
• GVFS

• David A. Rusling, « The File system », sur http://tldp.org (consulté le 23 septembre 2006)
• ???, « Linux Virtual File System » [archive du 24 septembre 2006], sur http://people.clarkson.edu (consulté le 23 septembre 2006)
• Tigran Aivazian, « Virtual Filesystem (VFS) », sur http://tldp.org, 2002 (consulté le 23 septembre 2006)

• La thèse de Heidemann en anglais : (en) John Shelby Heidemann, Stackable Layers : An Architecture for File System Development, University of California, 1991 (lire en ligne).
• Une thèse sur VFS MINIX : (en) Balázs Gerõfi, Design and implementation of the MINIX Virtual File system, Vrije Universiteit amsterdam, 2006 (lire en ligne). Voir en particulier les pp. 55-60, pour une histoire des VFS sur les systèmes UNIX et Linux.
• Andrew Tanenbaum, Systèmes d’exploitation, Pearson, 2008, 3^e éd. [détail de l’édition], pp.831-832.