Worldlex Wiki - Une copie de sauvegarde du superbloc
- En-tête de groupe de cylindres, avec statistiques, listes de cylindres libres, etc., concernant ce groupe de cylindres, similaire à ceux du superbloc
- Un certain nombre d' inodes , chacun contenant des attributs de fichier
- Un certain nombre de blocs de données
Les inodes sont numérotés séquentiellement, en commençant par 0. L'inode 0 est réservé aux entrées de répertoire non allouées, l'inode 1 était l'inode du fichier de bloc défectueux dans les versions UNIX historiques, suivi de l'inode du répertoire racine , qui est toujours l'inode 2, et de l'inode du répertoire lost+found, qui est l'inode 3.
Les fichiers de répertoire contiennent uniquement la liste des noms de fichiers du répertoire et l'inode associé à chaque fichier. Toutes les métadonnées des fichiers sont stockées dans l'inode.
Histoire et évolution
Les premiers systèmes de fichiers Unix étaient simplement appelés FS . FS ne comprenait que le bloc d'amorçage, le superbloc, un ensemble d' inodes et les blocs de données. Cette architecture convenait aux petits disques pour lesquels les premiers systèmes Unix étaient conçus, mais avec l'évolution technologique et l'augmentation de la capacité des disques, les allers-retours incessants de la tête de lecture/écriture entre l'ensemble d'inodes et les blocs de données entraînaient un phénomène de « thrashing » . Marshall Kirk McKusick , alors étudiant diplômé à Berkeley , a optimisé l'organisation du FS de la version 7 pour créer le FFS (Fast File System) de BSD 4.2 en inventant les groupes de cylindres, qui divisent le disque en segments plus petits, chaque groupe possédant ses propres inodes et blocs de données.
L'objectif de BSD FFS est de tenter de localiser les blocs de données et les métadonnées associés dans le même groupe de cylindres et, idéalement, tout le contenu d'un répertoire (données et métadonnées de tous les fichiers) dans le même groupe de cylindres ou un groupe de cylindres voisin, réduisant ainsi la fragmentation causée par la dispersion du contenu d'un répertoire sur l'ensemble du disque.
Parmi les paramètres de performance du superbloc figuraient le nombre de pistes et de secteurs, la vitesse de rotation du disque, la vitesse de la tête de lecture/écriture et l'alignement des secteurs entre les pistes. Dans un système entièrement optimisé, la tête pouvait se déplacer entre des pistes proches pour lire des secteurs dispersés sur des pistes alternées, en attendant la rotation complète du plateau.
Avec l'augmentation de la capacité des disques, l'optimisation au niveau des secteurs est devenue obsolète (surtout pour les disques utilisant une numérotation linéaire des secteurs et un nombre variable de secteurs par piste). Avec des disques et des fichiers plus volumineux, les lectures fragmentées sont devenues un problème croissant. Pour y remédier, BSD a initialement augmenté la taille des blocs du système de fichiers d'un secteur à 1 Ko dans la version 4.0 ; puis, dans FFS, cette taille a été portée de 1 Ko à 8 Ko. Cette évolution a plusieurs conséquences : la probabilité que les secteurs d'un fichier soient contigus est bien plus élevée ; la surcharge liée à l'affichage des blocs du fichier est réduite, tandis que le nombre d'octets représentables par un nombre donné de blocs est augmenté.
Des disques de plus grande capacité sont également possibles, car le nombre maximal de blocs est limité par une taille de bloc fixe (en bits). Cependant, avec des blocs plus grands, les disques contenant de nombreux petits fichiers gaspillent de l'espace, chaque fichier devant occuper au moins un bloc. C'est pourquoi BSD a introduit la fragmentation au niveau bloc , également appelée sous-allocation de blocs, fusion de fragments ou compactage de fragments , qui permet de stocker le dernier bloc partiel de données de plusieurs fichiers dans un seul bloc « fragment » au lieu de plusieurs blocs majoritairement vides.
Les travaux sur Berkeley FFS ont été largement adoptés par d'autres fournisseurs Unix, et la famille de systèmes de fichiers qui en dérive est collectivement connue sous le nom d'UFS.
Mises en œuvre
Les fournisseurs de certains systèmes Unix propriétaires, tels que SunOS / Solaris , System V Release 4 , HP-UX et Tru64 UNIX , ainsi que de systèmes Unix ouverts dérivés comme illumos , ont adopté UFS.Solaris 7 , Sun Microsystems a intégré la journalisation UFS, qui a introduit la journalisation du système de fichiers UFS, toujours disponible dans les versions actuelles de Solaris et d'illumos. Solaris UFS propose également des extensions pour les fichiers et disques volumineux, ainsi que d'autres fonctionnalités.
Dans 4.4BSD et les systèmes Unix BSD qui en dérivent, tels que FreeBSD , NetBSD , OpenBSD et DragonFly BSD , l'implémentation d'UFS1 et d'UFS2 est divisée en deux couches : une couche supérieure qui fournit la structure de répertoires et gère les métadonnées (permissions, propriété, etc.) dans la structure des inodes, et des couches inférieures qui fournissent les conteneurs de données implémentés sous forme d'inodes. Cette architecture permet de prendre en charge à la fois le système de fichiers traditionnel FFS et le système de fichiers structuré en journal LFS , grâce à un code partagé pour les fonctions communes. La couche supérieure est appelée « UFS », et les couches inférieures sont appelées « FFS » et « LFS ». Dans certains de ces systèmes, le terme « FFS » désigne la combinaison de la couche inférieure FFS et de la couche supérieure UFS, et le terme « LFS » désigne la combinaison de la couche inférieure LFS et de la couche supérieure UFS.
McKusick a implémenté la réallocation de blocs, une technique qui réorganise les blocs du système de fichiers juste avant l'écriture afin de réduire la fragmentation et de limiter le vieillissement du système. Il a également implémenté les mises à jour logicielles , un mécanisme qui maintient la cohérence du système de fichiers sans en limiter les performances, contrairement au mode de synchronisation traditionnel. Ceci a pour effet secondaire de réduire la fréquence des vérifications du système de fichiers après un plantage ou une coupure de courant. Pour pallier les problèmes persistants après une panne, un utilitaire fsck exécuté en arrière-plan a été introduit.
Dans UFS2, McKusick et Poul-Henning Kamp ont étendu les couches FFS et UFS de FreeBSD en ajoutant des pointeurs de blocs 64 bits (permettant aux volumes d'atteindre 8 zébioctets ), des blocs de taille variable (similaires aux extents ), des champs d'indicateurs étendus, des horodatages supplémentaires, une prise en charge étendue des attributs et les listes de contrôle d'accès POSIX 1.e. UFS2 est devenue la version UFS prise en charge à partir de FreeBSD 5.0. FreeBSD a également introduit les mises à jour logicielles et la possibilité de créer des instantanés du système de fichiers pour UFS1 et UFS2. Ces fonctionnalités ont depuis été portées sur NetBSD, mais les mises à jour logicielles (appelées dépendances logicielles dans NetBSD) ont finalement été supprimées de NetBSD 6.0 au profit du mécanisme de journalisation du système de fichiers moins complexe appelé WAPBL (également appelé journalisation), qui a été ajouté à FFS dans NetBSD 5.0. OpenBSD a pris en charge les mises à jour logicielles depuis la version 2.9 jusqu'à leur abandon dans la version 7.4 , et prend en charge UFS2 (FFS2) (sans ACL) depuis la version 4.2 . OpenBSD a fait d'UFS2 la version UFS par défaut avec la version 6.7 . Depuis FreeBSD 7.0, UFS prend également en charge la journalisation du système de fichiers grâce au fournisseur GEOM gjournal . FreeBSD 9.0 ajoute la prise en charge d'une journalisation légère en plus des mises à jour logicielles (SU+J), ce qui réduit considérablement le besoin de fsck en arrière-plan et d'ACL NFSv4.
FreeBSD, NetBSD, OpenBSD et DragonFly BSD intègrent également le système Dirhash , développé par Ian Dowse. Ce système utilise une table de hachage en mémoire pour accélérer les recherches dans les répertoires. Dirhash résout ainsi plusieurs problèmes de performance liés aux répertoires volumineux sur UFS.NeXTStep , dérivé de BSD, utilisait également une version d'UFS. Sous Mac OS X d' Apple , il était disponible comme alternative à HFS+ , le système de fichiers propriétaire de l'entreprise. Cependant, à partir de Mac OS X Leopard , il n'était plus possible d'installer Mac OS X sur un volume formaté en UFS. De plus, la mise à niveau vers Leopard des anciennes versions de Mac OS X installées sur des volumes formatés en UFS nécessitait un reformatage du volume de démarrage. La taille des fichiers était limitée à 4 Go pour les disques formatés en UFS sous Mac OS X. Avec Mac OS X Lion , la prise en charge d'UFS a été complètement abandonnée.