HFS

Hierarchical File System (HFS), est un système de fichiers développé par Apple Inc. pour le système d'exploitation Mac OS. Conçu à l'origine pour les disquettes et disques dur, il peut également être utilisée sur des médias en lecture seule, comme les CD-ROM. HFS est généralement désigné par « Mac OS Standard », et son successeur HFS+ « Mac OS étendu ».

Hierarchical File System, ou HFS, est aussi un autre système de fichier trouvé dans Z / OS, un système d’exploitation IBM mainframe.

Histoire

HFS a été introduite par Apple en septembre 1985 pour remplacer Macintosh File System (MFS), le système de fichier d'origine qui a été présenté l'année précédente avec l'ordinateur Macintosh. Développé par Patrick Dirks et Bill Bruffey, HFS partagent un certain nombre de caractéristiques de conception avec MFS qui n'étaient pas disponibles dans d'autres systèmes de fichier de l'époque (tels que DOS et FAT). Les fichiers peuvent avoir plusieurs forks, ce qui a permis au code source d’être stocké séparément des ressources telles que les icônes qui pourraient avoir besoin d'être localisé. Les dossiers ont été référencés avec des identifiants uniques de fichier plutôt que des noms de fichier, et les noms de fichiers peuvent être long de 255 caractères (bien que le Finder supporte seulement 31 caractères).

MFS a été optimisé pour être utilisé sur de très petit et lents médias, comme les disquettes, HFS a été introduit de manière à surmonter certains des problèmes de performance qui sont arrivés avec l'introduction de plus grands médias, et notamment les disques dur. La principale préoccupation est le temps nécessaire pour afficher le contenu d'un dossier. Sous MFS tous les informations des fichiers et répertoires ont été stockées dans un fichier unique, qui, pour le système de recherche, construisait une liste des fichiers stockés dans un dossier particulier. Cela a bien fonctionné avec un système de quelques centaines de kilo-octets de stockage et, une centaine de dossiers, mais comme les systèmes passaient aux méga-octets, et aux milliers de fichiers, les performances se dégradaient rapidement.

La solution consiste à remplacer la structure de répertoires de MFS par une plus adaptée aux grands systèmes de fichiers. HFS remplace la table des fichiers par le Catalog File, qui utilise une structure arbre B et qui permet d'effectuer des recherches très rapidement quelle que soit la taille de l'arbre. HFS a aussi remodelé diverses structures pour être en mesure d'organiser un plus grand nombre de fichiers, les entiers 16 bits étant remplacés par des entiers 32 bits . Curieusement, il reste un relents de MFS : le Catalog File lui-même, qui limite HFS au stockage de 64 000 fichiers maximum.

Alors que HFS est un système de fichier propriétaire, il est fait de telle sorte qu'il existe des solutions d’utilisation des disques formatés HFS avec les systèmes d'exploitation plus modernes.

En 1998, Apple HFS+ trouve la répartition inefficace de l'espace disque en HFS et décide d’ajouter d'autres améliorations. HFS est encore lisible par les versions actuelles de Mac OS, mais sous Mac OS X un volume HFS ne peut pas être utilisé pour le boot un peu comme le Fat 16 et Windows NT.

Design

Le Hierarchical File System divise un volume logique en blocs de 512 octets. Ces blocs logiques sont ensuite regroupés dans des blocs d'allocation, qui peuvent contenir un ou plusieurs blocs logiques en fonction de la taille totale. HFS utilise une valeur de 16 bits pour l'attribution d'adresse de blocs, ce qui limite le nombre de blocs d'allocation à 65 536.

Il y a cinq structures qui forment un volume de HFS :

1. Blocs logiques 0 et 1 du volume sont les secteurs de Boot qui contiennent des informations sur le démarrage du système. Par exemple, les noms du Système et le Shell (habituellement le Finder) les fichiers qui sont chargés au démarrage.
2. Bloc logique 2 contient le Master Directory Block (alias MDB). Cela définit un large éventail d’informations sur le volume lui-même, par exemple date et heure de quand le volume a été créé, l'emplacement d'autres volumes de structures telles que la taille des structures logiques et telles que l'allocation des blocs. Il y a aussi un double de la MDB appelée Alternate Master Directory Block (alias Alternate MDB), situé à l'extrémité opposée du volume dans l’avant dernier bloc logique. Celui-ci sert principalement à l'usage des services publics et du disque quand la mise à jour du catalogue de fichiers ou Extents Overflow File sont installés.
3. Bloc logique 3 est le départ du Volume Bitmap, qui garde la trace de l'allocation des blocs qui sont en usage et qui sont libres. Chaque bloc d'allocation sur le volume est représenté par un une marque; S'il est clair, le bloc est libre d'être utilisé. Le Volume Bitmap doit avoir un peu d'allocation pour représenter chaque bloc, sa taille est déterminée par la taille du volume lui-même.
4. L’ Extents Overflow File est un B *-tree qui empêche le système de fichiers d'allouer un bloc défectueux dans un fichier.
5. Le Catalogue de fichier est un autre B *- tree, qui contient des enregistrements pour tous les fichiers et répertoires stockés dans le volume. Il stocke quatre types de documents. Chaque fichier est constitué d'un File Thread Record et d'un File Record tandis que chaque répertoire se compose d'un Directory Thread Record, Directory Record. Les fichiers et répertoires dans le catalogue de fichiers sont localisés par leur unique Catalogue Node ID (ou CNID).
   • Un File Thread Record stocke juste le nom du fichier et le CNID de son répertoire parent.
   • Un File Record stocke des métadonnées sur le fichier y compris ses CNID, de la taille du fichier, trois dates (quand le fichier a été créé, la dernière modification, la dernière sauvegarde). Le fichier stocke également deux champs de 16 octets qui sont utilisés par le Finder pour stocker les attributs sur les fichiers.
   • Un Directory Thread Record stocke juste le nom du répertoire et le CNID de son répertoire parent.
   • Un Directory Record stocke les données comme le nombre de fichiers stockés dans le répertoire, le CNID du répertoire, trois dates (quand le répertoire a été créé, avec la dernière modification, la dernière sauvegardés). Comme le File Record, le Directory Record stocke également deux champs de 16 octets utilisés par le Finder. Pour stocker des informations comme la largeur et la hauteur, les coordonnées x et y de la fenêtre, le mode d'affichage (icône, liste, etc) de la fenêtre et sa position dans la Barre de défilement.

Problèmes

Le catalogue de fichier, qui stocke tous les fichiers et répertoires des lignes en une seule structure de données, a des problèmes de performances lorsque le système permet le multitâche, un seul programme peut écrire sur un fichier à la fois, ce qui signifie que de nombreux programmes peuvent se retrouver dans la file d'attente a cause d’un "arc" dans le système. C'est aussi un sérieux problème, car les dommages à ce fichier peuvent détruire tout le système de fichiers. Cela contraste avec les autres systèmes de fichiers qui stockent les fichiers et les dossiers dans le répertoire des structures distinctes (comme Microsoft et FAT ou de l’Unix File System), où la structure est répartie dans l'ensemble du disque. Ce qui signifie qu'endommager un seul répertoire est généralement non-dangereux et les données peuvent éventuellement être récupérées avec des données détenues dans la partie non endommagée.

En outre, la limite de 65 535 allocation des blocs fichiers (clusters) ayant abouti à un "minimum" de taille équivalente à 1/65 535^e de la taille du disque. Ainsi, tout volume donné, peu importe sa taille, ne peut stocker qu'un maximum de 65 535 fichiers. En outre, tout fichier se verrait allouer plus d'espace que nécessaire, jusqu'à la taille des blocs d'allocation. Quand les disques étaient petits, cela était peu important, car la taille des blocs d'allocation individuelle était futile, mais dès que les disques ont commencé à approcher le 1 Gio, la plus petite quantité d'espace que peuvent occuper n'importe quel fichier (un seul bloc de l'allocation) est devenu trop grande, gaspillant beaucoup d'espace disque. Par exemple, sur un 1 Gio, la taille des blocs d'allocation avec HFS est 16 Kio, alors même un fichier de 1 octet peut prends 16 Kio d'espace disque. Cette situation est moins problématique pour les utilisateurs ayant de gros fichiers (comme les images, bases de données ou audio), parce que ces grands dossiers gaspillent moins d'espace. Les utilisateurs disposant d'un grand nombre de petits fichiers, d'autre part, pourraient perdre une abondante quantité d'espace due à la taille des blocs d'allocation. Ce découpage disque réalisé en petits volumes logiques est très attrayant pour les utilisateurs de Mac, parce que les petits documents stockés sur un plus petit volume prendrait beaucoup moins de place que s'ils résidaient sur une grande partition. Le même problème existe dans le FAT 16.

• Portail Apple