Quelle place occupe réellement un fichier sur un disque ?

Une histoire de secteurs

Dans un ordinateur, pour accéder aux données stockées dans une mémoire, on utilise une adresse. Chaque donnée accessible à sa propre adresse unique. Par exemple le premier octet d'une mémoire peut avoir l'adresse 0x00000000, le second octet l'adresse 0x00000001 et ainsi de suite.

Le problème c'est qu'un disque dur est un stockage de grande capacité (aujourd'hui on peut trouver des disques de plusieurs dizaines de téra-octets). Ils contiennent tellement d'octets qu'on ne peut pas adresser individuellement chacun d'entre eux, ou en tout cas pas de manière efficace. Ils sont donc regroupés en « paquets » que l'on appelle des secteurs (ou sectors en anglais), qui eux sont adressables. Ces secteurs sont donc, en quelque sorte, l'unité de base de nos disques durs.

Sur les disques durs les plus anciens, on regroupait généralement les octets par paquets de 512. Sur les disques modernes, du fait de leur grande capacité, les secteurs font généralement 4 kio (4096 octets).

Dans le cas de notre image disque au format VHD, les secteurs font 512 octets.

Et puis il y a les clusters

Côté matériel, on regroupe donc les octets en secteurs. Maintenant passons au système de fichier. Lui aussi il aime bien regrouper les octets — ou plus précisément les secteurs — en paquets, que l'on nomme de différentes manières suivant les OS et les systèmes de fichier... 😅️

Suivant les cas on les appellera donc « blocks », « cluster » ou encore « unité d'allocation » (allocation unit en anglais). Dans notre cas on gardera toutefois la dénomination de « cluster » qui est celle utilisée par Microsoft dans son système de fichier NTFS.

La taille de ces clusters n'est pas libre, il faut respecter certaines contraintes. Dans le cas de NTFS, la taille des clusters sera toujours une puissance de 2, multipliée par la taille des secteurs du disque.

Secteur vs cluster

Sur un disque ayant des secteurs de 512 octets, un cluster NTFS pourra donc faire 512 octets (1 secteur), 1024 octets (2 secteurs) ou encore 4096 octets (8 secteurs). Sur un disque avec des secteurs de 4 kio (4096 octets), un cluster NTFS fera au minimum 4 kio et pourra monter jusqu'à 2 Mio.

En pratique la taille des clusters dépend de la capacité de notre volume et est définie lors du formatage de la partition. Avec des clusters de 4 kio on peut aller jusqu'à des volumes de 16 Tio, mais pour des capacités plus importantes on devra utiliser des clusters plus grands. NTFS supporte des clusters d'une taille maximale de 2 Mio, qui permettent d'atteindre des capacités de 8 Pio [2].

Enfin bref. Dans mon cas, les clusters de mon système de fichier NTFS font 4 kio.

Dernière chose importante à savoir sur les clusters c'est qu'il s'agit du plus petit élément que l'on peut allouer pour stocker des données sur le disque. Si on veut écrire 1 octet, il faut donc allouer un cluster complet.

Stockage des fichiers

Sur un système de fichier NTFS, le contenu de nos fichiers est stocké dans un ou plusieurs clusters, en fonction de la quantité de données à stocker. Un cluster ne peut contenir les données que d'un seul fichier ; deux fichiers ne peuvent pas partager le même cluster.

En plus du contenu d'un fichier, il faut stocker ses métadonnées (son nom, ses permissions, la date de création et de dernière modification, la liste des clusters qui contiennent les données, etc.). Ces métadonnées sont stockées dans des structures nommées « File Records », qui sont elles-mêmes stockées dans un fichier spécial nommé $MFT (pour Master File Table). Les File Records ont une taille fixe, qui est presque toujours de 1024 octets (1 kio) [3].

On peut donc se représenter le stockage d'un fichier de la manière suivante :

Schéma du stockage d'un fichier sur une partition NTFS

Donc si on a un fichier de 1 octet, que l'on stocke sur un système de fichier NTFS qui a des clusters de 4 kio et des File Records de 1 kio, on peut en arriver à la conclusion qu'il occupe effectivement 5 kio sur le disque (1 kio dans la MFT + 1 cluster de 4 kio)... Voilà, problème résolu ! 😁️

... Mais en fait non, car les choses ne sont pas si simples ! Et pour comprendre ça, il faut que je parle plus en détail de la MFT et des enregistrements qu'elle contient.

Chaque File Record contient différents attributs, et ce sont ces attributs qui stockent tout ce qui concerne nos fichiers. On va par exemple retrouver des attributs comme :

• $STANDARD_INFORMATION qui contient les infos de base comme les dates de création, modification, dernier accès au fichier, le propriétaire du fichier,...

• $FILE_NAME qui contient le nom du fichier (sous la forme d'une chaine Unicode, donc chaque caractère occupe 2 octets).

  Et à vrai dire on peut retrouver cet attribut en double : un avec le nom long du fichier (celui que vous voyez dans l'explorateur de fichier) et un autre avec le nom court, aussi appelé « 8.3 filename ». Ce nom est utilisé pour la compatibilité avec les vieux vieux logiciels et est composé d'un nom de 8 caractères maximum suivi d'un point et d'une extension de 3 caractères maximum (8.3, vous l'avez ? 😁️).

  Exemple de short name : "MYTEXT~1.TXT" au lieu de "MyTextFile.txt".

• $DATA qui contient les données du fichier (oui les données du fichier en elles-mêmes sont aussi un attribut).

Et il y en a bien d'autres mais on ne va pas rentrer dans les détails.

Ces attributs peuvent être de deux types différents :

• résidents : ils sont stockés directement dans le File Record dans la MFT,
• non-résidents : ils sont stockés dans des clusters spécialement alloués pour eux (l'attribut dans le File Record référence alors ces clusters).

Certains attributs comme $FILE_NAME sont toujours résidents, ils ne peuvent pas être stockés ailleurs. D'autres comme $DATA peuvent être résidents ou non-résidents : s'il y a la place ils sont stockés sur place, dans la MFT, et si ça rentre pas, bah on les colle dehors dans des clusters. Et pour finir certains sont toujours non-résidents, comme $INDEX_ALLOCATION dont on reparlera plus tard.

Vous commencez à le voir venir ? Si un fichier est tout petit, il est possible qu'il soit stocké directement dans la MFT. Si on reprend notre fichier de 1 octet... Et bah il est probable qu'il n'occupe en fait qu'1 kio sur notre disque.

Schéma du stockage d'un fichier résidant dans la MFT sur une partition NTFS

C'est quoi un petit fichier ?

Les petits fichiers peuvent donc être directement stockés dans la MFT. Toute la difficulté ici est d'évaluer si un fichier est assez petit pour tenir dans la MFT ou pas. Il est très difficile de déterminer ça de manière totalement sûre, c'est pourquoi on va l'estimer à la louche. Dans mon cas, je suis parti sur le calcul suivant :

400 + FILE_NAME × 2 + DATA

Où :

• 400 est une estimation large de la taille occupée par les éléments fixes, les entêtes, les attributs qui ne m'intéressent pas et le nom court que je considère toujours présent (même si en pratique c'est pas forcément le cas).
• FILE_NAME × 2 est la taille occupée par le nom du fichier (nombre de caractères multiplié par 2 car il s'agit d'une chaine Unicode).
• DATA est la taille des données.

Si le résultat de ce calcul est inférieur ou égal à la taille d'un File Record (1 kio) alors je considère que $DATA est résident et donc que le fichier est stocké dans la MFT (taille = 1 kio). Sinon je considère qu'il est non-résident et qu'il est donc stocké en dehors de la MFT (taille = 1 kio + n × 4 kio, où n est le nombre suffisant de cluster pour contenir le fichier).

Ici l'estimation est assez large (vaut mieux prévoir plus de place que pas assez), mais sur un grand nombre de fichiers, on tombe pas loin de la vérité.

Petite expérience

Pour illustrer un peu ce qu'on vient de voir, on va faire une petite expérience que je trouve intéressante.

Je crée 2 fichiers parfaitement identiques de 600 octets précisément. L'un sera nommé "a.txt" et l'autre "abcdefghijklmnopqrstuvwxyz.txt". Voici ce que nous apprend Windows sur l'espace disque qu'ils occupent :

Capture d'écran des fenêtres de propriété de nos deux fichiers

• Pour le premier Windows indique qu'il occupe 0 octet sur le disque, malgré le fait que la taille brute du fichier est bien rapportée (600 octets). Cela s'explique par le fait qu'aucun cluster n'a été alloué pour le fichier, et que Windows ne tient pas compte de la place occupée dans la MFT.
• Et pour le second il nous dit qu'il occupe 4096 octets sur le disque... soit 1 cluster (toujours pas de prise en compte de l'enregistrement dans la MFT).

La seule différence entre ces deux fichiers est le nom. Pour le second fichier, le nom occupe plus de place dans le File Record et il n'en reste plus assez pour y stocker directement le contenu du fichier, un cluster est donc alloué.

Et les dossiers dans tout ça ?

On voit généralement les dossiers comme un élément d'organisation, et on oublie souvent qu'eux-mêmes occupent de la place sur le disque. Certes assez peu, mais quand même !

Dans NTFS, tout est fichier, et les dossiers ne font pas exception. Ils sont donc présents dans la MFT au côté des autres fichiers. On peut donc déjà en conclure qu'ils prennent au moins 1 kio d'espace disque.

Mais les dossiers stockent également une référence vers tous les fichiers qu'ils contiennent... ainsi qu'une copie de leurs noms (courts et longs). Un dossier vide occupera donc 1 kio, mais un dossier contenant de nombreux fichiers (et/ou avec des noms très longs) prendra davantage de place.

Dans le File Record d'un dossier, la liste des fichiers est contenue dans l'attribut $INDEX_ROOT, qui est toujours résident. Lorsque le dossier contient trop de fichiers et que ça ne rentre plus, un second attribut nommé $INDEX_ALLOCATION est ajouté. Cet attribut est toujours non-résident et des clusters dédiés lui sont donc alloués. Il est important de noter que ce nouvel attribut ne remplace pas le précédent, il le complète (on y met ce qui ne rentre pas dans le premier).

Pour un dossier vide ou peu rempli on se retrouve donc avec : taille = 1 kio, et pour les dossiers plus volumineux on a le calcul suivant : taille = 1 kio + n × 4 kio, exactement comme pour les fichiers contenant des données.

Comment estimer la place occupée par un dossier ?

Eh bah on va s'y prendre comme pour les fichiers : on va estimer si on a à faire à un « petit » dossier ou pas, en utilisant des estimations larges. Pour ma part je suis parti sur le calcul suivant :

[400] + [FOLDER_NAME × 2] + [FILE_NAMES × 2 + FILE_COUNT × 82] + [FILE_COUNT × 112]

Comme le calcul est un peu plus compliqué que celui des fichiers, j'ai regroupé les termes entre crochets pour pouvoir détailler tout ça. Nous avons donc :

• 400 qui est comme tout à l'heure une estimation large de la place occupée par les éléments fixes et autres entêtes.
• FOLDER_NAME × 2 est la taille occupée par le nom du dossier (×2 car il s'agit toujours d'une chaîne Unicode).
• FILE_NAMES × 2 + FILE_COUNT × 82 est la place totale occupée par le nom long des fichiers contenus dans le dossier que l'on cherche à estimer (82 ici est la place occupée par chaque champ de nom, que l'on doit répéter pour chaque élément).
• FILE_COUNT × 112 est la place totale occupée par les noms courts (8.3 filenames) des fichiers, que l'on considère toujours présents et toujours à 12 caractères au total (là encore il faut savoir que ce n'est pas toujours le cas en pratique mais pour notre estimation ça fera l'affaire).

Avec le résultat de ce calcul on fait la même supposition qu'avec les fichiers : si le tout fait moins de 1024 alors on considère que tout rentre dans la MFT et donc le dossier occupe 1 kio. Et si ça dépasse alors on part sur 1 kio + n × 4 kio où n est le nombre de clusters nécessaires pour stocker les noms courts et longs de l'ensemble des fichiers.

Étant donné qu'en pratique les noms de certains fichiers resteront stockés dans l'attribut résident $INDEX_ROOT, on risque de surestimer le nombre de clusters nécessaires, mais on fera avec... 😄️