Aujourd'hui, la plupart des systèmes de gestion de bases de données ( PostGreSQL , MongoDB , etc., par exemple ) conservent leurs données en interne dans des fichiers de système d'exploitation (certains SGBD utilisaient auparavant directement des partitions de disque brutes).
Sur les ordinateurs récents qui utilisent encore des disques durs en rotation , le disque est si lent - par rapport au processeur ou à la RAM - que l’ajout de quelques couches logicielles n’est pas pertinent. La technologie SSD peut changer cela un peu, et certains systèmes de fichiers sont optimisés pour les SSD.
Les fichiers sont présents dans la plupart des systèmes d’exploitation en général pour des raisons historiques et sociales (en particulier, les compilateurs C et la plupart des outils - éditeurs, éditeurs de liens - veulent des fichiers, il existe donc un problème de type poule et œuf), et parce qu’il existe de très bons fichiers. implémentations du système .
En passant, certaines installations système essentielles peuvent utiliser des bases de données. Par exemple, sur Linux, PAM peut être configuré pour utiliser des informations dans des bases de données (mais cela est rarement fait en pratique). En outre, certains serveurs de messagerie peuvent stocker une partie ou la plupart de leurs données dans des bases de données (par exemple, Exim ).
Les fichiers sont des abstractions légèrement inférieures aux bases de données, ils peuvent donc être plus faciles à implémenter (comme les systèmes de fichiers et la couche VFS dans le noyau Linux) et plus rapides à utiliser. En particulier, les opérations sur les fichiers sont beaucoup plus restreintes que celles sur les bases de données. En fait, vous pourriez voir des fichiers ou des systèmes de fichiers comme des bases de données très restreintes!
Vous pouvez concevoir un système d' exploitation sans aucun fichier , mais avec une autre orthogonale la persistance des machines (par exemple , ayant tous les processus persistants, alors vous ne se soucient pas beaucoup explicitement sur le stockage, car le système d' exploitation gère les ressources persistantes). Cela a été fait dans plusieurs systèmes d'exploitation académiques (1) (ainsi que dans les machines Smalltalk et Lisp des années 1980, dans IBM System i , AS / 400 , et dans certains projets de jouets liés à osdev).), mais lorsque vous concevez votre système d'exploitation de cette manière, vous ne pouvez pas tirer parti de nombreux outils existants (par exemple, vous devez également créer votre compilateur et votre interface utilisateur à partir de zéro, ce qui représente beaucoup de travail).
Notez que les systèmes d’exploitation à micro - noyau peuvent ne pas nécessiter de fichiers fournis par les couches du noyau, car ils ne sont que des serveurs d’applications (par exemple, des traducteurs Hurd fonctionnant en mode utilisateur). Regardez aussi l' approche unikernel dans MirageOS d'aujourd'hui
Linux (et probablement Windows, qui tire principalement son inspiration de VMS et Unix ) a besoin de fichiers pour fonctionner. À tout le moins, le programme init (le premier programme démarré par le noyau) doit être un exécutable stocké dans un fichier (souvent /sbin/init
, mais il pourrait être systemd de nos jours), et (presque) tous les autres programmes sont lancés avec execve (2). ) syscall doit donc être stocké dans un fichier. Cependant, FUSE vous permet de donner une sémantique semblable à un fichier à des choses qui ne sont pas des fichiers.
Notez également que sous Linux (et peut-être même Windows, que je ne connais pas et que je n’ai jamais utilisé), sqlite est une bibliothèque qui gère une base de données SQL dans des fichiers et fournit une API pour cela. Il est bien connu qu'Android (une variante de Linux) utilise beaucoup de fichiers sqlite (mais il possède toujours un système de fichiers de type POSIX).
Lisez également sur le point de contrôle des applications (qui, sur de nombreux systèmes d’exploitation actuels, est implémenté pour écrire l’état du processus dans des fichiers). Poussée à l'extrême, cette approche n'a pas besoin d'écrire manuellement les fichiers de l'application (mais uniquement de conserver l'état complet du processus à l'aide de la machine à points de contrôle).
En fait, la question intéressante est de savoir pourquoi les systèmes d’exploitation actuels utilisent encore des fichiers, et la réponse est un héritage et des raisons économiques et culturelles (malheureusement, la plupart des langages de programmation et des bibliothèques veulent encore des fichiers).
Note 1: Les systèmes d’exploitation académiques persistants incluent Lisaac & Grasshopper , mais ces projets académiques semblent inactifs. Regardez aussi dans http://tunes.org/ ; il est inactif, mais a beaucoup de discussions autour de tels sujets.
Note 2: la notion de fichier a beaucoup évolué au fil du temps (regardez cette réponse à propos de mes premières expériences de programmation): le premier MSDOS sur PC IBM des années 1980 (pas de répertoires!), Le VMS (1978) Vaxen - (à enregistrement fixe) fichiers et fichiers séquentiels, avec un système de gestion des versions primitif), les ordinateurs centraux des années 1970 ( IBM / 370 avec OS / VS2 MVS ) avaient une notion très différente de fichiers et de systèmes de fichiers (en particulier parce qu’à leur époque le rapport temps d ’accès au disque dur Le temps d’accès à la mémoire principale était de quelques milliers d’années. Ainsi, à l’époque, le disque était relativement plus rapide qu’aujourd’hui, même si les disques actuels sont absolumentplus rapide qu'au siècle précédent, le rapport de la vitesse CPU / disque est aujourd'hui d'environ un million; mais nous avons maintenant des disques SSD). De plus, les fichiers sont moins utiles (ou même pas utiles) lorsque la mémoire est persistante (comme sur le tambour magnétique CAB500 , années 1960 ou sur les futurs ordinateurs utilisant MRAM ).