Je lisais quelque chose de similaire hier à propos d'OSX et c'est la compression du système de fichiers - Fondamentalement, la réponse tourne autour de ce que vous voulez compresser - dans cet exemple, il parle des données "FAT"; structures de fichiers, propriétés, métadonnées, etc. qui, lorsqu'ils sont stockés ensemble, peuvent être compressés pour économiser de l'espace et être lus dans le processeur plus rapidement que de rechercher la tête partout pour trouver les données de chaque fichier ...
Quoi qu'il en soit, vaut la peine d'être lu si vous pensez à de telles choses :-p
Mais la compression ne consiste pas seulement à économiser de l'espace disque. C'est également un exemple classique d'échange de cycles CPU pour une latence d'E / S et une bande passante réduites. Au cours des dernières décennies, les performances du processeur se sont améliorées (et les ressources informatiques sont plus abondantes - plus à ce sujet plus tard) à un rythme beaucoup plus rapide que les performances du disque ont augmenté. Les temps de recherche de disque dur modernes et les retards de rotation sont toujours mesurés en millisecondes. En une milliseconde, un processeur à 2 GHz passe par deux millions de cycles. Et puis, bien sûr, il y a encore le temps de transfert de données réel à considérer.
Certes, plusieurs niveaux de mise en cache dans le système d'exploitation et le matériel fonctionnent puissamment pour masquer ces retards. Mais ces bits doivent sortir du disque à un moment donné pour remplir ces caches. La compression signifie que moins de bits doivent être transférés. Étant donné la surabondance presque comique des ressources du processeur sur un Mac multicœur moderne dans des conditions normales d'utilisation, le temps total nécessaire pour transférer une charge utile compressée à partir du disque et utiliser le processeur pour décompresser son contenu en mémoire sera généralement bien inférieur au temps il faudrait pour transférer les données sous forme non compressée.
Cela explique les avantages potentiels en termes de performances du transfert de moins de données, mais l'utilisation d'attributs étendus pour stocker le contenu des fichiers peut également accélérer les choses. Tout cela a à voir avec la localisation des données.
S'il y a une chose qui ralentit un disque dur plus que de transférer une grande quantité de données, c'est de déplacer ses têtes d'une partie du disque à une autre. Chaque mouvement signifie que la tête doit commencer à bouger, puis s'arrêter, puis s'assurer qu'elle est correctement positionnée sur l'emplacement souhaité, puis attendre que le disque en rotation place les bits souhaités en dessous. Ce sont toutes des parties réelles, physiques et mobiles, et il est étonnant qu'elles fassent leur danse aussi rapidement et efficacement qu'elles le font, mais la physique a ses limites. Ces mouvements sont les véritables tueurs de performances pour le stockage en rotation comme les disques durs.
Le format de volume HFS + stocke toutes ses informations sur les fichiers (métadonnées) dans deux emplacements principaux sur le disque: le fichier de catalogue, qui stocke les dates, les autorisations, la propriété et bien d'autres choses, et le fichier d'attributs, qui stocke les «fourches nommées . "
Les attributs étendus dans HFS + sont implémentés en tant que fourches nommées dans le fichier d'attributs. Mais contrairement aux fourchettes de ressources, qui peuvent être très volumineuses (jusqu'à la taille de fichier maximale prise en charge par le système de fichiers), les attributs étendus dans HFS + sont stockés "en ligne" dans le fichier d'attributs. En pratique, cela signifie une limite d'environ 128 octets par attribut. Mais cela signifie également que la tête de disque n'a pas besoin de se déplacer vers une autre partie du disque pour obtenir les données réelles.
Comme vous pouvez l'imaginer, les blocs de disques qui composent les fichiers de catalogue et d'attributs sont fréquemment consultés, et donc plus susceptibles que la plupart d'être dans un cache quelque part. Tout cela conspire à faire du stockage complet d'un fichier, y compris ses métadonnées dans ses données, dans les fichiers de catalogue et d'attributs structurés en arborescence B un gain de performance global. Même une charge utile de huit octets qui monte à 25 octets n'est pas un problème, tant qu'elle est toujours inférieure à la taille du bloc d'allocation pour le stockage de données normal, et tant qu'elle tient toutes dans un nœud d'arbre B dans le fichier d'attributs qui l'OS doit quand même lire dans son intégralité.
Il existe d'autres contributions importantes à la réduction de l'encombrement du disque de Snow Leopard (par exemple, la suppression des localisations inutiles et des fichiers "designable.nib"), mais la compression HFS + est de loin la plus intéressante sur le plan technique.
