K-Tux

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.

Les types de filesystem.

Les classiques.

Lorsque vous installez votre Linux, sachez que vous avez la possibilité de choisir votre filesystem, et de le partitionner vous-même (c’est-à-dire le scinder en morceau de disque). Par défaut, Linux, dans ses versions récentes, installera votre filesystem sous ext4 -Extended FileSystem- (Ubuntu Karmic Koala, Fedora 12 Constantine, …). Mais comme cela est si bien dit dans les notes d’Ubuntu, cela ne signifie pas que les autres filesystems ne sont plus supportés. Il existe en effet, historiquement, d’autres versions d’ext : ext2, ext3 sont les plus souvent rencontrées (au-delà, votre serveur est vraiment vieux).

Ah. Question au fond. La différence ? Entre ? AAAH !!!

Déjà, entre ext2 et ext3, nous avons principalement une différence au niveau de la journalisation. En effet, ext2 est un des dinosaures de Linux. Il était certes plus intelligent que le FAT de Windows, en ce sens qu’il organisait les fichiers et donc limitait le recours à la fragmentation, mais il restait perfectible. Vous en avez révé ? Ext3 l’a fait ! La journalisation sert essentiellement à maintenir la cohérence des métadonnées, notamment en cas de crash. Cela évite par exemple le gentil fsck de ext2 lorsque le système a subi un arrêt impromptu. Le système relit tranquillement son fichier de log, retrace les dernières transactions non commitées et remet d’aplomb un système sain en 2 temps trois mouvements. Hop, ne soyons pas radin, un peu de doc vous fera du bien !

Ext3 et Ext4, c’est une autre histoire. Ext4 est une évolution puisqu’étant encore attaché à la compatibilité descendante, il reste limité dans ses mouvements. Ext4 oriente la majorité de son travail sur les problèmes de tailles et de fragmentation. Hop, moment opportun pour un petit lien d’info sur Linuxfr.org et sur le Wiki officiel Ext4.

Ext3 et Ext4 sont principalement utilisés, ce sont eux qui supportent votre Linux. Ils peuvent travailler sur disques durs, sur volumes logiques, sur partition raid, toussa toussa, sans broncher (ou si peu).

Les outils et fichier impliqués font partie du noyau Linux depuis belle lurette, ce sont, entre autre :

• fdisk : permet de manipuler / voir / gérer les partitions,
• mkfs.ext2 ou mkfs.ext3 : créer le système de fichier (respectivement ext2 ou ext3),
• fsck : monitorer et réparer votre système de fichier,
• resize2fs : redimensionner le filesystem,
• mount : « monter », c’est-à-dire rendre accessible en lecture (et, pourquoi pas, en écriture-exécution) un système de fichier,
• /etc/fstab : fichier de configuration pour les montages automatiques au démarrage des différents filesystems. Par défaut, votre filesystem est déjà monté et inscrit dans ce fichier.

Les extensibles et les hautes disponibilités.

Lorsque l’on donne, dans son immense bonté, vie à une machine Linux, elle a, comme tout être vivant, un cycle de vie. Parce que oui, dans un contexte généralisé, votre machine aussi a besoin de grandir, en terme de composant, de performances, de service et d’espace.

Il existe plusieurs moyens permettant de construire et d’étendre un système de fichier. Certaines approches nécessitent un travail de réflexion en amont, à savoir si réellement on a besoin de rajouter de l’espace, si ce doit être opérationnel sans avoir à réinstaller, rapidement, de manière modulaire, si il y a une forte contrainte de temps et de disponibilité,… Bref, plus on veut, plus fallait réfléchir avant.

De même, souhaitons-nous recourir à des outils qui ont fait leurs preuves depuis des années, des solutions toutes packagées, principalement hardware, ou bien préférerons-nous les versions plus intelligentes, plus intuitives, plus modulables ? Les alternatives sont nombreuses, et je ne les maîtrise pas toutes.

RAID. Voilà le premier point qu’il vous vient à l’esprit.

Un RAID (Redundant Array of Inexpensive Disks) est une agrégation de device de stockage qui permet d’avoir une tolérance aux éventuels accidents (panne, crash d’un disque dur,…) et qui améliore les performances d’accès aux données. En effet, composé de plusieurs disques, cela lui permet d’une part d’étaler les données sur l’ensemble des disques, mais en plus, et c’est vital, de rajouter des brides d’information concernant ces données tour à tour sur chacun des disques (RAID 5). Ces bribes d’information (bits de parité) sont stockés dans des stripes et servent à contrôler les données ajoutées et, au besoin, de les reconstruire. En conséquence, puisque ces données sont éclatées sur plusieurs disques, les temps d’accès en lecture et en écriture sont grandement améliorés.

Notre ami Wiki est toujours là pour vous.

Construire un RAID -logiciel, j’entends, puisqu’il n’y a jamais assez de moyens pour le tout packagé et qu’on est curieux de savoir ce qu’il y a sous le capot-, et surtout le maintenir, ce n’est pas de tout repos. Dans la meilleure des configurations, il vous faut n fois le même genre de disque dur (capacité, mémoire cache, vitesse, connectique), sinon le bonus de capacité qu’un disque pourrait avoir sur les autres sera jeté aux oubliettes. Il vous faut aussi, de préférence (mais c’est comme dans la vraie vie, tout est une histoire de bon matériel au bon moment) des disques en spare, histoire que vous ne soyez pas en position malheureuse si un autre « incident » survenait. De même, en cas de fail d’une unité du raid, la reconstruction des données peut prendre du temps.

Le RAID est une bonne solution concernant la scalabilité et la haute disponibilité, mais ce n’est pas un système de fichier, c’est une technologie. Vos meilleurs amis seront :

• mdadm : monitorer, créer, gérer le raid,
• mkraid : créer un raid,
• lsraid : lister les composants du (des) raid(s),
• raidhotadd : ajout à chaud de volume dans le raid,
• raidsetfaulty : forcer la sortie d’une volume en le mettant en faulty,
• raidstop, raidstart,…
• mknod : créer un fichier spécial block ou character
• /etc/raidtab : fichier de configuration d’un raid (optionnel)
• /proc/mdstat : fichier monitorant l’état du raid (pensez à watch pour le visionner en temps réel),
• /var/log/messages : log système,
• tous les outils gérant le filesystem sous-jacent.

Resté sur votre faim ? Par ici !

Une autre façon de faire serait de passer par LVM (Logical Volume Manager).

La principale différence entre RAID et LVM, c’est que justement LVM n’est pas un RAID. LVM ne travaille pas directement sur les disques, mais sur des entités appelées Logical Volumes, crées, maintenus et gérés par tout un arsenal d’outil rattachés au package lvm2. LVM apporte donc un niveau d’abstraction supplémentaire qui permet à vous, utilisateur et administrateur, de pouvoir redimensionner, créer, supprimer, étendre,… vos partitions sans avoir à vous soucier du hardware en dessous.

Plus en détail, LVM décompose le disque dur en pv, physical volumes, qu’il regroupe au sein d’un vg, Volume Group, et sur lequel il crée un lv, Logical Volume. C’est sur le Logical Volume que le filesystem s’installe, donc « quelque part » sur le Volume Group. Il est vraiment très facile d’étendre et de shrinker (réduire) l’espace disque.

LVM est très stable, éprouvé en production, modulable à souhait, un brin plus souple que le RAID, et plus que propice à la scalabilité mais en revanche, il n’aide pas niveau haute-disponibilité. Il est cependant possible d’utiliser LVM sur un RAID pour ajouter les avantages du RAID -et ses inconvénients par la même occasion- à ceux de LVM.

Les outils qui vous aideront :

• lvm2 : le package de référence,
• pv{change||ck||create||display||move||remove||resize||display||scan||s} : gestion des physical volumes (par exemple, pvcreate /dev/sda2),
• vg{cfgbackup||cfgrestore||change||ck||convert||create||display||export||extend||import
  ||merge||mknodes||reduce||remove||rename||s||scan||split} : gestion des volume groups,
• lv{change||convert||create||display||extend||reduce||remove||rename||resize||s||scan} : gestion des logical volumes,
• lvm{||change||diskscan||dump||sadc||sar} : gestion lvm.

Si vous voulez en venir aux mains, faites.

Le dernier point que je souhaiterais voir avec vous au niveau des extensibles et hautement disponibles, se cache sous trois lettres : ZFS.

ZFS, contrairement aux deux autres points, est un filesystem à part entière, il ne s’agit donc pas d’un outil. Zeta Filesystem, de son petit nom, a été développé par Sun. Ce système de fichier présente des caractéristiques très particulières mais n’est pas intégré au noyau Linux pour une raison simple : la licence sous lequel il est distribué (CDDL) est incompatible avec GPL dans sa version 2. Mais là encore, grâce à Ricardo Correia, développeur, nous pouvons utiliser ZFS via fuse (filesystem in userspace), environnement qui met à disposition, comme son nom l’indique, les fonctionnalités des filesystems dans l’espace User.

ZFS constitue un peu le fantasme de tout administrateur système. Il fait en sorte d’être toujours cohérent. Oui. Vous avez bien entendu. Il se corrige tout seul. Cette citation à elle seule, comme ça, sans preuve peut choquer. De même, il fournit une très haute capacité de stockage (nettement plus haute que tous les autres filesystems d’après notre ami Wiki). Voyons comment tout ça fonctionne.

Eh bien ZFS nous rappelle un peu le fonctionnement de LVM. En effet, notre filesystem s’appuie en réalité sur des pools de stockage. Les pools permettent, comme on l’a vu précédemment, d’éviter de se soucier du hardware, partionnement compris. Dans ZFS, ils sont utilisés pour centraliser les IO (entrées-sorties) et comme lien entre les différents périphériques de stockage. Lorsqu’une donnée est destinée à être écrite sur un disque, elle passe par le pool, à ce moment-là, elle est vérifiée à la volée, dupliquée, puis stockée. ZFS dispose donc de tous les éléments nécessaires pour contrôler à n’importe quel moment la cohérence et la véracité des données et va même jusqu’à corriger la donnée corrompue sans que vous ayez à le lui demander.

De la même manière, ZFS s’appuie sur du RAID Z, qui est un peu semblable à notre bon vieux RAID 5, à la différence que les stripes de données ont une largeur variable, de sorte que ZFS limite les pertes d’espace disque à leur origine.

Si vous avez envie d’en savoir plus, jetez un coup d’oeil sur le site officiel, la doc officielle, et l’article d’Unix Garden sur sa mise en place. Sachez aussi que ZFS est présent nativement sous OpenSolaris, version Open Source de Solaris.

Il existe beaucoup d’autres qui mériteraient d’être dans cette catégorie, mais j’arrêterais là. Sachez que je vous encourage à participer si vous estimez qu’il manque vraiment quelque chose.

C’est tout pour la première partie et encore !!! Je suis loin d’être exhaustive, même en me cantonnant à Linux.

Sur ce, potassez bien, farmez, complétez et n’oubliez pas de passer de Bonnes Fêtes -oui, un ASR aussi, ça se repose parfois- !!!