Nos amis les Filesystems… Part I

Bonjour readers et readeuses acharnés.

Aujourd’hui, nous allons parler des différents système de fichiers -Filesystem, pour briller en société- qui font la richesse et la pluridisciplinarité de Linux, et comme il y en a beaucoup et de toutes sortes, nous allons découper ça bien propre en plusieurs parties. Utilisateur Windows, ne t’inquiète pas ! Ton heure viendra, mais pas tout de suite quand même, parce que, même avec Windows 7 (dites Séveuuun), il y a encore un petit bout de chemin à faire.

Avertissement pour les puristes de la technique :

Cette note est tournée grand public et la mise en œuvre des techniques décrites ci-dessous ne sera pas détaillée, même si quelques liens propices vous guideront vers des howtos bien ficelés.

Petites généralités.

Selon notre ami Wikipédia, un système de fichier est un ensemble structuré qui permet d’organiser, de localiser, d’accéder et de maintenir des données. Le tout sur un support persistant, c’est-à-dire qui gardera les informations en l’état à l’extinction de la machine. Le plus communément, c’est donc sur votre (vos ?) disque(s) dur(s) que vous retrouverez vos fichiers.

Afin de pouvoir maintenir toutes ces informations, le système de fichier crée lui-même d’autres informations, relatives, elles, aux fichiers en eux-même. C’est ce que l’on appelle des métadonnées. Sous Linux, ce sont les inodes qui contiennent ces métadonnées. Les inodes sont des structures de données contenant toutes les informations utiles d’un fichier, permissions comprises. Elles sont liées aux fichiers par une autre structure de données, le dentry. Les fichiers, les inodes et les dentries sont contenus dans ce que l’on appelle le superblock, entité qui est chargée de la maintenance et de la gestion de la structure de donnée. Il contient le nom du filesystem (par exemple ext4), sa taille, son état, des métadonnées et une référence aux bloc devices. Le superbloc est la racine du filesystem.

Pour votre curiosité, Windows, lui, stocke directement ces métadonnées dans le fichier lui-même.

De visu, le système de fichier se présente comme une arborescence de répertoires dont la racine est /:

/

/bin /boot /dev /etc /home /lib /lib64 /lost+found /media /mnt /opt /proc /root /sbin /tmp /usr /var

Ce que vous ne voyez pas, mais que vous avez pu rencontrer si vous avez, par curiosité ou par science, partitionné votre disque manuellement, c’est la swap.

La swap est en fait une petite partie du disque réservée à la mémoire. Du fait qu’elle soit située sur le disque, elle est beaucoup plus lente d’accès que la mémoire vive en elle-même, mais elle présente un avantage dans le cas où vous êtes submergé par une occupation excessive de la mémoire vive par un ou plusieurs processus. Dans ce cas, au lieu de vous bloquer définitivement pour cause de pénurie de RAM, on utilise la swap. Une règle de pouce consiste à créer une swap de taille égale à la quantité de RAM présente sur la machine.

Organisation logique.

Mais revenons-en à nos moutons. Vous vous doutez bien qu’avec la quantité et la diversité des médias existants en ce bas-monde, le système de fichier Linux ne peut raisonnablement pas être livré tel quel, figé sur une implémentation pure et dure qui serait relative à un et un seul type de média, ni être décliné pour chacun des médias existant sur cette petite planète. D’une part parce qu’il en existe vraiment beaucoup, et d’autre part parce que cela nécessiterait de faire massivement évoluer le code lors d’une évolution de média. Bref, pas du tout portable, aucune scalabilité, le cauchemar. Il en est tout autrement.

User-Space, Kernel-Space.

En effet, le système de fichier Linux distingue 2 couches abstraites. Pourquoi ? Et bien pour séparer les traitements effectués par le système de fichier des manipulations de device à proprement parler.

Le schéma parle de lui-même. Nous pouvons donc voir que toutes les interactions avec le User-Space (autrement dit, tout ce qui touche à l’environnement utilisateur) passe par l’interface SYSTEM CALL, Kernel-Space qui, elle-même, devra s’adresser à un système de fichier virtuel (VFS) pour que ses traitements soient effectués à proprement dit. VFS abstrait les interfaces qui lui viennent d’un export de l’individual filesystem. Il gère également les informations concernant les filesystems supportés et ceux actuellement montés (oui, promis, j’expliquerais « monter »). Individual Filesystem, à l’origine de l’export des interfaces, fonctionnera très différemment selon le filesystem choisi (ext2, ext3, JFS, …). Des caches sont présents à différent niveau afin d’optimiser le temps de traitement (Inode cache, Directory cache, Buffer cache).

Ok, je sens que je vais un peu loin alors je vais arrêter là. Pour ceux qui en veulent plus, n’hésitez plus, allez farmer un peu sur le Net.