C’est quoi un système de fichiers ?

closeCet article a été publié il y a 7 ans 7 mois 1 jour, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Merci Djerfy de m’avoir encore donné une idée à me donner un mal de crâne, trouver les mots justes pour vous introduire au merveilleux monde du stockage de données en ce dimanche toujours chaud, et plus particulièrement d’un élément primordial, le système de fichiers. En effet, nos données numériques sont devenues centrales de nos jours, aussi bien pour nous que les sociétés qui se font du beurre dessus. Plongée dans un univers qui se retrouve jusque dans vos poches.

Disclaimer : je vais vraiment me concentrer sur les systèmes de fichiers, je n’aborderai pas le partitionnement, la notion de volume, les différences entre BIOS et UEFI… Aujourd’hui, c’est théorie du stockage.

Pour la faire courte, un système de fichiers est une mécanisme permettant d’ordonner et d’identifier les données sur un support de stockage. En effet, si l’on avait qu’à bourrer nos fichiers les uns à la suite des autres, les retrouver prendrait beaucoup de temps sans organisation. Mais ce n’est pas tout.

De mutiples tâches

On le verra, un système de fichiers a aussi la charge de s’assurer que les données restent intactes. Il est également possible qu’on lui confie des informations sur la gestion de droits utilisateurs, certains sont spécialisés pour pouvoir se répliquer d’eux-mêmes sur d’autres machines, d’autres permettent de prendre des instantanés, pour par exemple revenir en arrière en cas de problèmes…

Certains sont spécialisés dans un support de stockage particulier, d’autres possèdent des fonctions de chiffrements avancés, un mécanismes de compression à la volée, certains embarquent une journalisation pour améliorer la cohérence des données… Bref, énormément de facettes. Le dossier des sources du noyau Linux qui regroupe les systèmes de fichier en dénombre plus de 80. Comprenez que je vous évite la liste exhaustive.

Un héritage aussi vieux que les supports

Beaucoup de systèmes de fichiers (que je vais abréger en FS, pour FileSystem, l’équivalent shakespearien), créés à partir des années 70, ont eu pour mission « d’aligner » les données par rapport aux contraintes physiques des supports de l’époque. Pour prendre l’exemple du bon vieux disque dur à plateau encore utilisé aujourd’hui, celui-ci est généralement « découpé » en secteurs, qui peuvent contenir un certain nombre de blocs, qui sont les fragments de vos données. Celles-ci sont donc découpées en blocs de la taille de ceux « configurés » physiquement pour accélérer la vitesse d’écriture et lecture (un bloc étant écrit d’un trait, idem pour la lecture). Ce découpage physique rend le déplacement du bras sur la plateau plus rapide, le secteur étant identifié directement. On pourrait comparer aux centres de tri du courrier qui doivent déterminer vers quel centre local envoyer un courrier en fonction de l’adresse postale. Le code postal est l’une de ces informations qui permettent d’éviter à votre enveloppe de parcourir les 90% du pays.

Un principe de fonctionnement finalement assez simple

Pour ainsi dire, tous les FS ou presque reposent sur quelques mécaniques de base, la première étant la table des matières. À l’image de celles des livres, lorsque vous voulez accéder à un fichier, la table des matières est consultée pour récupérer l’emplacement du fichier, du premier au dernier bloc (on verra après pourquoi je précise). On sait donc exactement où se trouve le fichier, ce qui permet de s’y rendre très rapidement. Et je parle là d’emplacement physique, évidemment.

L’autre point commun à tout le monde ou presque est l’organisation en arborescences de dossiers. Une image valant mieux qu’un long discours, petit exemple d’un système de fichiers « unix-like » :

tree-file-system

C’est la même chose pour Windows, à part que vous avez un « arbre » par lettre attribuée à un volume (C:, D:…). Il y a bien quelques tentatives pour changer un peu ce paradigme (coucou WinFS), mais pour l’instant, le dossier reste maître, l’arbre est indéracinable.

Les attributs sont aussi assez répandus. Tous ne se retrouvent pas partout, la différence la plus facile à trouver est l’attribut de fichier caché. Sous Windows, c’est un attribut, sous Linux, il suffit que le nom du fichier commence par un point. Il ne faut pas les confondre avec les droits d’accès, qui travaillent en conjonction avec l’information du nom du propriétaire et du groupe du fichier à qui il appartient. Sous Linux vous pouvez par exemple, si votre FS utilise un mécanisme de compression à la volée, contrôler le comportement de la compression avec ces attributs.

De plus en plus, les FS reposent également sur un système de journalisation, qui permet de s’assurer qu’en cas d’interruption brutale, mettons de l’alimentation, vous ne vous retrouviez pas avec par exemple un fichier à moitié écrit (avec une information prétendant que le fichier est complet), une défragmentation laissée dans un état bancal (des blocs en cours de déplacement, et donc leurs informations pas à jour), bref, quelque chose de pas très beau. Chacun a ses propres méthodes de journalisation, mais l’essentiel est là : le journal permet de savoir où le système de fichiers en était avant coupure.

Le problème de la fragmentation

On vous propose souvent, quand votre ordinateur commence à ralentir sans raison apparente, de « défragmenter ». Mais déjà, pour commencer, c’est quoi la fragmentation ?

Quand vous écrivez un nouveau fichier sur le disque, il prend une certaine place. Si vous écrivez un nouveau fichier, le système le place à la suite du premier fichier, et ainsi de suite. Quand vous supprimez un fichier, l’espace libéré est réutilisable, mais quand vous avez un plus grand fichier que le « trou » disponible, votre fichier, qui pour rappel est découpé en blocs, commence à être écrit dans cet espace, et la fin est écrite ailleurs. Rassurez-vous, la table des matières est là pour noter l’emplacement de tous les fragments. Malgré tout, avec le temps, et même si les SSD ont tendance à gommer ce problème (ils en ont d’autres, inhérents à leur conception mais ça dépasse le cadre du billet), l’accès à de nombreux fichiers ainsi fragmentés peut s’avérer plus long, puisqu’on appelle plusieurs zones éloignées physiquement sur le disque. Conséquence, « ça gratte ».

Supprimez le fichier 2, Ajoutez le fichier 4 trop gros pour la place laissée par fichier 2

Supprimez le fichier 2, Ajoutez le fichier 4 trop gros pour la place laissée par fichier 2

La défragmentation consiste donc à réorganiser physiquement les fichiers pour en recoller tous les morceaux et ainsi éviter les allers-retours. Une opération souvent longue et qui peut accélérer le vieillissement de votre support. Il existe malgré tout quelques techniques pour réduire le plus possible la fragmentation, et certains FS s’en sortent mieux que d’autres. Par exemple, chercher systématiquement une zone libre suffisamment grande pour écrire ledit fichier, et ne fragmenter qu’en dernier recours. On peut aussi pré-allouer certains blocs supplémentaires, dans le cadre de fichiers qui sont amenés à grossir en taille, comme des fichiers de logs ou de base de données, même si cette technique a forcément ses limites.

Et oui, désolé, mais la fragmentation ça existe aussi sous Linux. Juste les FS sont globalement plus efficace pour l’éviter. Mais à un moment donné, si l’utilisateur remplit régulièrement son volume, la fragmentation est inévitable. Et plus les « trous » sont petits, pire ça deviendra.

La spécificité de l’inode

C’est un terme que vous ne rencontrerez pas sous Windows, mais c’est toujours intéressant à connaître. Un inode est une structure de données qu’on utilise pour représenter un objet du FS, que ce soit un fichier, un dossier, un descripteur pour un socket, un périphérique (sous unix, tout est fichier)… C’est dans l’inode que sont stockés notamment les attributs d’un fichier (rappel, à ne pas confondre avec les droits d’accès).

Le nombre d’inodes est fixe, et est calculé en fonction de la taille du FS (elle-même souvent en corrélation avec la taille de la partition). Pour une utilisation standard, tout va généralement pour le mieux, mais dans certains cas, si vous générez beaucoup, beaucoup d’objets (petits fichiers, arborescences à rallonge), vous pouvez réserver tous les inodes avant même de remplir la partition. Car oui, quelque soit la taille de votre fichier, vous réservez un inode, point barre. La seule solution est donc de « faire le ménage », soit en déplaçant/supprimant des fichiers, soit, s’il reste encore un poil de place, de regrouper plusieurs fichiers au sein d’une seule archive. Un groupe de fichiers ne réservera donc plus qu’un seul inode, par contre, il faudra le « désarchiver » pour en lire le contenu.

Un bon ami, qui peut se retourner contre vous

En effet, et j’ai déjà eu l’occasion de l’évoquer dans le passé, quand vous supprimez un fichier, au final, vous ne faites que supprimer sa référence dans la table des matières. Conséquence, les blocs restent physiquement présents jusqu’à ce que quelque chose soit écrit par dessus. Il est donc possible de retrouver des informations que vous pensiez détruites, comme je l’ai fait avec un premier disque dur dont l’auteur pensait avoir définitivement supprimé le contenu. Dans ce même billet je vous donne des conseils pour bien se débarrasser d’un fichier, et les FS étant utilisés partout, vous comprendrez que tout le monde est concerné, jusqu’à nos smarthpones qu’on jette si facilement lorsqu’ils commencent à défaillir.

La « couche » la plus haute de votre stockage

En effet, avec cet article j’aurai abordé la dernière étape de la chaîne que constitue le stockage, après avoir abordé la plus basse avec la partie physique, et notamment le SSD. Il restera donc à évoquer le partitionnement, que l’on « fusionne » souvent au quotidien avec le système de fichiers (alors qu’une partition contient un système de fichiers), et éventuellement, l’abstraction de ce partitionnement, avec ce merveilleux outil qu’est LVM (surtout dans un contexte de virtualisation). Mais ça sera pour une autre fois.

5 Commentaires
Le plus ancien
Le plus récent
Commentaires en ligne
Afficher tous les commentaires
Angristan
28/08/2016 20:07

Super intéressant, vivement les prochains articles 🙂

Wonderfall
28/08/2016 22:37

Salut, juste une petite note concernant les inodes : certains FS comme btrfs proposent une allocation dynamique des inodes, comme ça plus de limitation. 🙂

Wonderfall
29/08/2016 20:12
Répondre à  Seboss666

Oui c’est ça, par contre je ne suis pas du tout au courant pour XFS en tant que choix par défaut de certaines distribs. Je ne suis plus trop à vrai dire. Mais je sais qu’openSUSE propose depuis assez longtemps (2013 quand je l’utilisais) btrfs par défaut. Finalement on ne sait toujours pas si btrfs est assez mature ou non, en 2016. Quant à XFS pour moi ça répondait à un certain besoin, le stockage de gros fichiers, où il excelle. Ah et je me demande ce que devient ReiserFS qui était très performant, m’enfin avec l’histoire de son créateur… Lire la suite »

Apollo
Apollo
07/09/2016 17:28

Super article, cela m’a éclairci quelques notions 😉