• 3 Votes
    1 Messages
    34 Vues

    => Article complet : nextinpact.com <=

    Bon alors : quand ?

    Après plusieurs articles sur la FAT32, NTFS, HFS+ ou encore APFS, il est temps de se tourner vers l’univers Linux, et plus particulièrement les deux systèmes de fichiers que l’on y trouve le plus souvent : ext4 et Btrfs. Ils se côtoient souvent, mais leur fonctionnement est très différent.

    Lire notre dossier sur les systèmes de fichiers :

    | Qu’est-ce qu’un système de fichiers ? | Systèmes de fichiers : FAT12 à 32 et exFAT, conçus pour le grand public | Systèmes de fichiers : NTFS et ReFS, pensés d’abord pour l’entreprise | Systèmes de fichiers : de HFS et ses évolutions à APFS chez Apple | Systèmes de fichiers : ext4 et Btrfs, les « frères ennemis » du monde Linux

    Dans l’univers Linux, l’immense majorité des distributions se sert du même système de fichiers depuis longtemps : ext4. Le chiffre fait référence à la version. Il s’agit de la quatrième itération, même si l’on ne parlait pas vraiment à l’origine de « version » à proprement parler.

    De nombreux utilisateurs francophones ignorent peut-être que la toute première version d’ext a été développée par un Français : Rémy Card. Docteur en informatique et actuellement responsable du pôle « Exploitation et Infrastructures » de la DSI de la Sorbonne, il a développé ce système de fichiers pour dépasser les limitations imposées par Minix fs, lui-même une version simplifiée du système de fichiers Unix. Parmi ces limites, on trouvait notamment une limite de 64 Mo pour la taille des partitions, ou encore des noms de fichiers ne pouvant pas dépasser 14 caractères.

    Le système ext – extended file system – est intégré pour la première fois dans la version 0.96c du noyau Linux en 1992. Parmi ses apports, des partitions et des fichiers pouvant grimper jusqu’à 2 Go, ainsi que des noms de fichiers jusqu’à 255 caractères. Il garde la sémantique Unix et les bases posées précédemment, notamment les inodes.

    Ces derniers sont centraux dans l’univers UNIX/Linux et étaient déjà présents dans Minix. Un inode est une structure contenant la description d’un fichier : son type, les droits d’accès, les propriétaires, les horodatages, la taille ainsi que des pointeurs vers des blocs de données. Toutes les adresses de blocs d’un fichier sont contenues dans son inode. Aussi, lorsqu’une opération d’entrée/sortie sur un fichier est demandée par l’utilisateur, le noyau convertit la demande en numéro inode, lui-même permettant ensuite d’accéder à tous les blocs du fichier.

    Chaque dossier contient la liste des inodes des fichiers qu’il contient, selon le modèle suivant :

    inode

    Pour autant, il ne va pas rester en place bien longtemps, ext2 étant proposé dès l’année suivante.

    Cette évolution du premier ext vient en corriger les principaux défauts et étendre ses capacités. Alors que la taille des partitions avait fait un bond avec ext, ext2 propulse cette limite à 4 To (théoriquement jusqu’à 32 To). Si la taille maximale des fichiers n’évolue pas dans un premier temps (2 Go), elle le fera au cours des années suivantes, pouvant grimper jusqu’à 2 To.

    Lorsque ext3 apparait en 2001, il introduit un apport majeur : la journalisation. Avec ext2 en effet, en cas de corruption de la structure des données (suite par exemple à une extinction mal faite de l’ordinateur), l’outil fsck (file system check) pouvait prendre beaucoup de temps à faire son travail.

    Cette journalisation, contrairement à celle d’APFS par exemple, est totale. Elle concerne aussi bien les données que les métadonnées. L’idée générale reste cependant la même : les données et métadonnées sont entreposées dans une zone spécifique du disque, et ne sont intégrées dans la structure principale qu’à l’instant où le système de fichiers reçoit la confirmation que les informations ont été correctement écrites. Le journal est ensuite mis à jour. Au démarrage suivant, ce dernier sera analysé à la recherche d’opérations non terminées, qui seront alors répercutées si aucune erreur n’a été rencontrée.

    En revanche, et comme on s’en doute venant d’un mécanisme pensé pour la fiabilité, la journalisation a un impact négatif sur les performances en écriture. Initialement, on pouvait d’ailleurs la paramétrer selon trois paliers, du plus performant au plus sécurisé. Il était également possible de la désactiver, auquel cas la partition fonctionnait comme ext2.

    ext4 l’omniprésent

    L’arrivée d’ext4 en version stable le 24 décembre 2008 est un tournant majeur pour les systèmes de fichiers sous Linux. Ironie de l’histoire, il n’était prévu que comme une solution temporaire en attendant l’arrivée d’un système de fichiers plus moderne, à l’instar de Btrfs. Pourtant, 15 ans plus tard, il est toujours là, qui plus est sur pratiquement toutes les distributions Linux. Il n’est plus porté par Rémy Card.

    Les caractéristiques principales d’ext4 sont celles d’un système de fichiers tout ce qu’il y a de plus moderne. Les partitions peuvent grimper jusqu’à 1 Eo (un million de To), et les fichiers jusqu’à 16 To. Ces derniers peuvent être 4 milliards par volume. La limite de sous-dossiers passe également de 32 000 dans ext3 à 64 000. Les inodes voient leur taille passer à 256 octets (contre 128 pour ext3) et les horodatages abandonnent les secondes pour les nanosecondes.

    Les extents, petite révolution en leur temps

    Surtout, ext4 apporte plusieurs évolutions importantes, dont la principale est le mécanisme d’extent. Pour le comprendre, il faut se pencher un instant sur la manière dont un système de fichiers alloue l’espace aux données. ext2 et ext3 proposaient des schémas de mappage de blocs direct, indirect, double indirect et triple indirect. Sans plonger dans les détails, retenez que ces solutions sont très adaptées pour de nombreux petits fichiers, mais pas pour les gros. Avec ces derniers, ces schémas créent un grand nombre de mappages, réduisant les performances générales, surtout lors d’opérations comme la recherche ou l’effacement de données.

    De son côté, un extent est défini par une séquence contiguë de blocs physiques. La création d’un fichier entraine celle d’un extent. Si le fichier est amené à grossir, les données ultérieures sont simplement inscrites à la suite de celles existantes au sein du même extent. Quand le fichier devient volumineux, plusieurs extents sont utilisés. L’inode d’un fichier peut stocker jusqu’à quatre extents, après quoi le reste est stocké dans un arbre H (similaire à l’arbre B vu dans ce précédent article). Les blocs étant contigus, les extents réduisent fortement la fragmentation et augmentent les performances vis-à-vis d’ext3. Des intentions confirmées dès décembre 2008 par Phoronix dans une série de benchmarks. Précisons que les extents étaient une option au début d’ext4, mais qu’ils sont devenus activés par défaut avec le noyau Linux 2.6.23.

    Souplesse dans l’allocation des blocs

    Cette hausse de performances est également alimentée par plusieurs capacités d’allocation, comme le multi-blocs. Si ext3 allouait les blocs un par un, ext4 peut le faire pour de multiples blocs en une seule opération, diminuant la charge du processeur et la quantité de mémoire vive utilisée. ext4 peut également faire de l’allocation différée, aussi appelée allocation à la volée. Si une opération écrit des données sans les allouer d’une seule traite, elles seront stockées dans un cache. Quand les tâches d’écriture sont terminées, le cache est vidé (allocate-on-flush) et les données sont allouées dans un extent. Ces deux types d’allocation réduisent elles aussi la fragmentation.

    ext4 peut aussi faire de la préallocation persistante. Elle reprend les mêmes avantages sur la fragmentation que les autres, mais permet en plus aux applications de s’assurer que suffisamment d’espace est disponible avant d’écrire des données. Le mécanisme convient très bien par exemple aux bases de données ou aux processus chargés de diffuser du contenu en continu.

    Notez que les extents ne sont pas une capacité unique d’ext4. Ce mécanisme d’allocation est par exemple présent dans NTFS chez Microsoft, dans HFS+ et APFS chez Apple, dans le HPFS d’OS/2, le BFS de BeOS ou encore dans des systèmes de fichiers plus récents comme Btrfs. Par ailleurs, si les systèmes de fichiers ext ont réduit la fragmentation version après version, ils ne l’ont pas totalement supprimée. Dans ext4, il existe un outil, e4defrag, dédié à cette tâche, capable d’agir aussi bien sur un fichier spécifique qu’un dossier ou un volume. Comme pour NTFS, le passage aux SSD met fin au problème.

    Fiable et éprouvé, en attendant « mieux »

    Outre ces aspects, ext4 gère d’autres caractéristiques, comme une double compatibilité ascendante/descendante avec les versions antérieures du système de fichiers (bien que plus limitée avec l’activation par défaut des extents), les attributs étendus (xattr), les quotas et leur journalisation (plus besoin des longues vérifications de leur cohérence), le chiffrement des données (depuis le noyau Linux 4.1) ou encore, bien sûr, la gestion des droits.

    Une précision enfin sur l’accès depuis les autres plateformes. Dans l’absolu, il est possible de lire, voire d’écrire des données sur une partition ext4 depuis Windows ou macOS, mais pas sans utiliser un outil tiers, qu’ils soient libres (ext2read, LinuxReader, etx4fuse…) ou payants, comme les produits vendus par Paragon.

    Aujourd’hui, ext4 est donc omniprésent. Peu de distributions Linux se servent d’autre chose, l’un des cas les plus emblématiques étant Fedora, dont la version 33 a adopté Btrfs pour les nouveaux volumes formatés par une installation neuve du système. Mais puisque l’on parle justement de Btrfs, pourquoi ce système de fichiers, en version stable depuis longtemps, n’est-il pas encore celui fourni par défaut sur les autres systèmes ? Nous allons nous pencher sur la question.

    Btrfs, un gros projet

    Parlons maintenant du système de fichiers qui doit prendre le relai, tout du moins dans une partie des distributions Linux. Btrfs est loin d’être un projet neuf, puisque la première version stable dans le noyau Linux 3.10 est sortie le 29 juillet 2013 (oui, Btrfs fête ses dix ans demain). Avant cette étape, il a passé plus de quatre ans en statut instable, après son arrivée dans le noyau Linux 2.6.29. Une gestation assez longue, dont on pourrait dire qu’elle n’est pas tout à fait terminée, tant Btrfs met du temps à parvenir jusque dans les installations par défaut.

    Btrfs est initialement un projet commun de plusieurs entreprises, dont Fujitsu, Intel, Oracle, Red Hat (qui depuis s’est retiré) ou encore SUSE. Développé en open source (licence GPL), il tient son nom de l’arbre B (dont nous avons déjà parlé dans notre article sur NTFS) : B-tree file system, que l’on prononce « ButterFS ». Ses caractéristiques de base sont clairement modernes : 16 Eo de taille maximale pour les volumes et les fichiers, 2^64 fichiers possibles par volume, noms jusqu’à 255 caractères, attributs POSIX et étendus, reprise des extents…

    La protection et l’intégrité des données avant tout

    […]

    Source et suite : nextinpact.com