Hierarchical File System

HFS
Développeur	Apple Inc.
Nom anglais	Hierarchical File System
Introduction	17 juillet 1985 (System 2.1)
Identificateur de partition	Apple HFS (Apple Partition Map) 0xAF (MBR)
Structure
Contenu des répertoires	B* tree
Allocation de fichiers	Bitmap
Mauvais blocs	B* tree
Limitations
Taille maximale de fichier	2 Gio
Nombre maximal de fichiers	65 535
Taille maximale du nom de fichiers	31 caracteres
Taille maximale de volume	2 Tio
Caractères autorisés dans les noms de fichiers	Toutes les valeurs 8-bit values excepté « : ».
Fonctionnalités
Dates enregistrées	Création, modification, backup
Plage de dates	1er janvier 1904 - 6 Fevrier 2040
Forks	Seulement 2 (données et ressources)
Attributs	Couleur (3 bits), verrouillage, icônes personnalisable, archive, caché, alias, systeme, inited, no INIT resources, partage, bureau
Permissions	AppleShare
Compression intégrée	Oui (Troisieme partie), Stacker
Chiffrement intégré	Non
modifier

Le Hierarchical File System (HFS), est un système de fichiers développé par Apple pour le système d'exploitation Mac OS. Conçu à l'origine pour les disquettes et disques dur, il peut également être utilisé 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+ par « Mac OS étendu ».

Le Hierarchical File System, ou HFS, est aussi un autre système de fichiers utilisé dans z/OS, un système d’exploitation IBM pour mainframe.

Histoire

HFS a été introduit 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 partage 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 permet au code source d’être stocké séparément des ressources telles que les icônes pour les rendre faciles à localiser (adapter à divers pays). 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 petits et lents médias, comme les disquettes. HFS a été introduit de manière à surmonter certains des problèmes de performance liés à 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 utilisaient des méga-octets et des milliers de fichiers, les performances se dégradaient rapidement.

Pour s'adapter 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 et, pour pouvoir organiser un plus grand nombre de fichiers, utilise des entiers 32 bits (au lieu de 16). Mais, comme pour MFS, le Catalog File lui-même 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 publie HFS+ à cause de la répartition inefficace de l'espace disque en HFS. Ce nouveau système apporte 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 (démarrage), tout comme les versions récentes de Windows ne peuvent plus être installées sur une partition FAT 16.

Conception

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. Les 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. Le bloc logique 2 contient le Master Directory Block (alias MDB). Ce MDB définit un large éventail d’informations sur le volume lui-même, par exemple les date et heure de création, l'emplacement d'autres volumes, les tailles des structures logiques et l'allocation des blocs. Il y a aussi un double de la MDB appelé 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. Le bloc logique 3 est le départ du Volume Bitmap, qui garde la trace de l'allocation des blocs utilisés ou libres. Chaque bloc d'allocation sur le volume est représenté par une marque; S'il est libre, le bloc peut être utilisé. La taille du Volume Bitmap est déterminée par la taille du volume lui-même.
4. L’Extents Overflow File est un B *-tree qui permet au système de gérer les blocs 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, la taille du fichier, trois dates (de création, de dernière modification et de 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 (de création, de dernière modification et de dernière sauvegarde). Comme le File Record, le Directory Record stocke deux champs de 16 octets utilisés par le Finder. Pour stocker des informations d'affichage comme la largeur et la hauteur, les coordonnées x et y de la fenêtre, le mode d'affichage (icône, liste, etc.) et sa position dans la barre de défilement.

Problèmes

Le catalogue de fichier, qui stocke tous les fichiers et répertoires 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 à cause d’un « arc » dans le système. Dans ce cas, les dommages à un 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 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 dans la partie non endommagée.

En outre, la limite de 65 535 allocations de blocs de fichiers (clusters) abouti à des blocs minimum de taille équivalente à 1/65 535^e de la taille du disque, même pour des fichiers ne contenant que quelques octets. Quand les disques étaient petits, cela était peu important, car la taille des blocs d'allocation individuelle était réduite, mais dès que les disques ont commencé à approcher le 1 Gio, cette taille de bloc minimum est devenu trop grande, gaspillant beaucoup d'espace disque. Par exemple, sur un disque de 1 Gio, la taille des blocs d'allocation avec HFS est de 16 Kio, même pour un fichier de 1 octet. Cette situation est moins problématique pour les utilisateurs ayant de gros fichiers (comme les images, bases de données ou audio), qui 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. Un découpage disque réalisé en petits volumes logiques (partitions) 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 sur une grande partition. Le même problème existe dans le FAT16.

• Portail d’Apple