La majorité des distributions Linux modernes utilisent par défaut le système de fichiers ext4, tout comme les distributions Linux précédentes utilisaient par défaut ext3, ext2 et, si vous remontez assez loin, ext.
Si vous êtes nouveau sur Linux - ou sur les systèmes de fichiers - vous vous demandez peut-être ce qu'ext4 apporte à la table qu'ext3 n'a pas fait. Vous pourriez également vous demander si ext4 est toujours en développement actif, étant donné les rafales de couverture médiatique des systèmes de fichiers alternatifs tels que btrfs, xfs et zfs.
Plus de ressources Linux
- Aide-mémoire des commandes Linux
- Aide-mémoire des commandes Linux avancées
- Cours en ligne gratuit :Présentation technique de RHEL
- Aide-mémoire sur le réseau Linux
- Aide-mémoire SELinux
- Aide-mémoire sur les commandes courantes de Linux
- Que sont les conteneurs Linux ?
- Nos derniers articles Linux
Nous ne pouvons pas tout couvrir sur les systèmes de fichiers dans un seul article, mais nous essaierons de vous mettre au courant de l'historique du système de fichiers par défaut de Linux, de sa position et de ce à quoi vous attendre.
J'ai beaucoup puisé dans les divers articles sur le système de fichiers ext de Wikipedia, les entrées wiki de kernel.org sur ext4 et mes propres expériences lors de la préparation de cet aperçu.
Un bref historique de l'extension
Système de fichiers MINIX
Avant qu'il y ait ext, il y avait le système de fichiers MINIX. Si vous n'êtes pas au courant de votre histoire Linux, MINIX était un très petit système d'exploitation de type Unix pour les micro-ordinateurs IBM PC/AT. Andrew Tannenbaum l'a développé à des fins pédagogiques et a publié son code source (sous forme imprimée !) en 1987.
Bien que vous puissiez consulter la source de MINIX, il ne s'agissait pas réellement d'un logiciel libre et open source (FOSS). Les éditeurs du livre de Tannebaum exigeaient des frais de licence de 69 $ pour exploiter MINIX, qui étaient inclus dans le coût du livre. Pourtant, c'était incroyablement peu coûteux pour l'époque, et l'adoption de MINIX a rapidement décollé, dépassant bientôt l'intention initiale de Tannenbaum de l'utiliser simplement pour enseigner le codage des systèmes d'exploitation. Dans les années 1990 et tout au long des années 1990, vous pouviez trouver des installations MINIX prospères dans les universités du monde entier - et un jeune Linus Torvalds a utilisé MINIX pour développer le noyau Linux original, annoncé pour la première fois en 1991 et publié sous licence GPL en décembre 1992.
Mais attendez, c'est un système de fichiers article, non ? Oui, et MINIX avait son propre système de fichiers, sur lequel les premières versions de Linux s'appuyaient également. Comme MINIX, il pourrait sans pitié être décrit comme un exemple "jouet" de son genre - le système de fichiers MINIX ne pouvait gérer que des noms de fichiers jusqu'à 14 caractères et n'adresser que 64 Mo de stockage. En 1991, le disque dur typique avait déjà une taille de 40 à 140 Mo. Linux avait clairement besoin d'un meilleur système de fichiers !
poste
Pendant que Linus piratait le tout nouveau noyau Linux, Rémy Card travaillait sur le premier système de fichiers ext. Implémenté pour la première fois en 1992, un an seulement après l'annonce initiale de Linux lui-même !, ext a résolu le pire des problèmes du système de fichiers MINIX.
L'extension de 1992 utilisait la nouvelle couche d'abstraction du système de fichiers virtuel (VFS) dans le noyau Linux. Contrairement au système de fichiers MINIX précédent, ext pouvait adresser jusqu'à 2 Go de stockage et gérer des noms de fichiers de 255 caractères.
Mais ext n'a pas eu un long règne, en grande partie à cause de son horodatage primitif (un seul horodatage par fichier, plutôt que les trois horodatages distincts pour la création d'inodes, l'accès aux fichiers et la modification de fichiers que nous connaissons aujourd'hui). À peine un an plus tard, ext2 a déjeuné.
post2
Rémy s'est clairement rendu compte assez rapidement des limites d'ext, puisqu'il a conçu ext2 pour le remplacer un an plus tard. Alors que ext avait encore ses racines dans les systèmes d'exploitation "jouets", ext2 a été conçu dès le départ comme un système de fichiers de qualité commerciale, selon les mêmes principes que le Berkeley Fast File System de BSD.
Ext2 offrait des tailles de fichiers maximales en gigaoctets et des tailles de système de fichiers en téraoctets, le plaçant fermement dans la cour des grands pour les années 1990. Il a été rapidement et largement adopté, à la fois dans le noyau Linux et éventuellement dans MINIX, ainsi que par des modules tiers le rendant disponible pour MacOS et Windows.
Il restait cependant des problèmes à résoudre :les systèmes de fichiers ext2, comme la plupart des systèmes de fichiers des années 1990, étaient sujets à une corruption catastrophique si le système tombait en panne ou perdait de l'alimentation pendant l'écriture des données sur le disque. Ils ont également souffert de pertes de performances importantes dues à la fragmentation (le stockage d'un seul fichier à plusieurs endroits, physiquement dispersé autour d'un disque rotatif) au fil du temps.
Malgré ces problèmes, ext2 est encore utilisé dans certains cas isolés aujourd'hui, le plus souvent comme format pour les clés USB portables.
poste3
En 1998, six ans après l'adoption d'ext2, Stephen Tweedie a annoncé qu'il travaillait à l'améliorer de manière significative. Cela est devenu ext3, qui a été adopté dans Linux principal avec la version 2.4.15 du noyau, en novembre 2001.
Ext2 avait très bien fonctionné pour la plupart des distributions Linux, mais - comme FAT, FAT32, HFS et d'autres systèmes de fichiers de l'époque - il était sujet à une corruption catastrophique lors d'une coupure de courant. Si vous perdez de l'énergie lors de l'écriture de données dans le système de fichiers, elles peuvent être laissées dans ce qu'on appelle une incohérence État - un état dans lequel les choses ont été laissées à moitié faites et à moitié défaites. Cela peut entraîner la perte ou la corruption de vastes pans de fichiers sans rapport avec celui qui est enregistré ou même l'impossibilité de monter l'ensemble du système de fichiers.
Ext3 et d'autres systèmes de fichiers de la fin des années 1990, tels que le NTFS de Microsoft, utilisent la journalisation pour résoudre ce problème. Le journal est une allocation spéciale sur disque où les écritures sont stockées dans les transactions; si la transaction finit d'écrire sur le disque, ses données dans le journal sont engagées au système de fichiers lui-même. Si le système plante avant que cette opération ne soit validée, le système nouvellement redémarré la reconnaît comme une transaction incomplète et l'annule comme si elle n'avait jamais eu lieu. Cela signifie que le fichier sur lequel on travaille peut toujours être perdu, mais le système de fichiers lui-même reste cohérent et toutes les autres données sont en sécurité. Trois niveaux de journalisation sont disponibles dans l'implémentation du noyau Linux d'ext3 :journal , commandé , et écriture différée .
- Journal est le mode le moins risqué, écrivant à la fois les données et les métadonnées dans le journal avant de le valider dans le système de fichiers. Cela garantit la cohérence du fichier en cours d'écriture, ainsi que du système de fichiers dans son ensemble, mais peut réduire considérablement les performances.
- Commandé est le mode par défaut dans la plupart des distributions Linux ; le mode ordonné écrit les métadonnées dans le journal mais valide les données directement dans le système de fichiers. Comme son nom l'indique, la commande des opérations ici est rigide :premièrement, les métadonnées sont attribuées au journal; deuxièmement, les données sont écrites dans le système de fichiers, et alors seulement les métadonnées associées dans le journal sont vidées dans le système de fichiers lui-même. Cela garantit qu'en cas de plantage, les métadonnées associées aux écritures incomplètes sont toujours dans le journal et que le système de fichiers peut nettoyer ces écritures incomplètes tout en annulant le journal. En mode ordonné, un plantage peut entraîner la corruption du ou des fichiers activement écrits pendant le plantage, mais le système de fichiers lui-même (et les fichiers non activement écrits) sont garantis sûrs.
- Réécriture est le troisième mode de journalisation, et le moins sûr. En mode écriture différée, comme le mode ordonné, les métadonnées sont journalisées, mais pas les données. Contrairement au mode ordonné, les métadonnées et les données peuvent être écrites dans n'importe quel ordre logique pour de meilleures performances. Cela peut offrir des augmentations significatives des performances, mais c'est beaucoup moins sûr. Bien que le mode d'écriture différée offre toujours une garantie de sécurité pour le système de fichiers lui-même, les fichiers qui ont été écrits pendant ou avant le crash sont vulnérables à la perte ou à la corruption.
Comme ext2 avant lui, ext3 utilise un adressage interne 16 bits. Cela signifie qu'avec une taille de bloc de 4 Ko, la plus grande taille de fichier qu'il peut gérer est de 2 Tio dans une taille de système de fichiers maximale de 16 Tio.
ext4
Theodore Ts'o (qui était alors le développeur principal d'ext3) a annoncé ext4 en 2006, et il a été ajouté à Linux principal deux ans plus tard, dans la version 2.6.28 du noyau. Ts'o décrit ext4 comme une technologie palliative qui étend considérablement ext3 mais qui dépend toujours de l'ancienne technologie. Il s'attend à ce qu'il soit éventuellement remplacé par un véritable système de fichiers de nouvelle génération.
Ext4 est fonctionnellement très similaire à ext3, mais apporte une prise en charge de systèmes de fichiers volumineux, une meilleure résistance à la fragmentation, des performances supérieures et des horodatages améliorés.
Ext4 contre ext3
Ext3 et ext4 présentent des différences très spécifiques, sur lesquelles je vais me concentrer ici.
Compatibilité descendante
Ext4 a été spécialement conçu pour être aussi rétrocompatible que possible avec ext3. Cela permet non seulement de mettre à niveau les systèmes de fichiers ext3 vers ext4 ; il permet également au pilote ext4 de monter automatiquement les systèmes de fichiers ext3 en mode ext3, ce qui rend inutile la maintenance des deux bases de code séparément.
Grands systèmes de fichiers
Les systèmes de fichiers Ext3 utilisaient un adressage 32 bits, les limitant à des fichiers de 2 Tio et à des systèmes de fichiers de 16 Tio (en supposant une taille de bloc de 4 Ko ; certains systèmes de fichiers ext3 utilisent des tailles de bloc plus petites et sont donc encore plus limités).
Ext4 utilise un adressage interne 48 bits, ce qui permet théoriquement d'allouer des fichiers jusqu'à 16 Tio sur des systèmes de fichiers jusqu'à 1 000 000 Tio (1 EiB). Les premières implémentations d'ext4 étaient encore limitées à 16 Tio de systèmes de fichiers par certains utilitaires de l'espace utilisateur, mais depuis 2011, e2fsprogs a directement pris en charge la création de systèmes de fichiers> 16 Tio ext4. Par exemple, Red Hat Enterprise Linux ne prend en charge contractuellement que les systèmes de fichiers ext4 jusqu'à 50 Tio et recommande des volumes ext4 ne dépassant pas 100 Tio.
Améliorations de l'allocation
Ext4 introduit de nombreuses améliorations dans la manière dont les blocs de stockage sont alloués avant de les écrire sur le disque, ce qui peut augmenter considérablement les performances de lecture et d'écriture.
Étendues
Une étendue est une plage de blocs physiques contigus (jusqu'à 128 Mio, en supposant une taille de bloc de 4 Kio) qui peuvent être réservés et adressés simultanément. L'utilisation d'étendues diminue le nombre d'inodes requis par un fichier donné et diminue considérablement la fragmentation et augmente les performances lors de l'écriture de fichiers volumineux.
Allocation multibloc
Ext3 a appelé son allocation de bloc une fois pour chaque nouveau bloc alloué. Cela pourrait facilement entraîner une forte fragmentation lorsque plusieurs écrivains sont ouverts simultanément. Cependant, ext4 utilise l'allocation différée, ce qui lui permet de fusionner les écritures et de prendre de meilleures décisions sur la façon d'allouer des blocs pour les écritures qu'il n'a pas encore validées.
Pré-allocation persistante
Lors de la pré-allocation d'espace disque pour un fichier, la plupart des systèmes de fichiers doivent écrire des zéros dans les blocs de ce fichier lors de sa création. Ext4 permet l'utilisation de fallocate() à la place, ce qui garantit la disponibilité de l'espace (et tente de lui trouver un espace contigu) sans avoir à y écrire au préalable. Cela augmente considérablement les performances des écritures et des lectures futures des données écrites pour les applications de streaming et de base de données.
Allocation différée
Il s'agit d'une fonctionnalité délicate et controversée. L'allocation différée permet à ext4 d'attendre pour allouer les blocs réels dans lesquels il écrira des données jusqu'à ce qu'il soit prêt à valider ces données sur le disque. (En revanche, ext3 allouerait des blocs immédiatement, même pendant que les données coulaient encore dans un cache en écriture.)
Retarder l'allocation des blocs à mesure que les données s'accumulent dans le cache permet au système de fichiers de faire des choix plus sains sur la façon d'allouer ces blocs, réduisant la fragmentation (écriture et, plus tard, lecture) et augmentant considérablement les performances. Malheureusement, il augmente le potentiel de perte de données dans les programmes qui n'ont pas été spécifiquement écrits pour appeler fsync() lorsque le programmeur veut s'assurer que les données ont été entièrement vidées sur le disque.
Supposons qu'un programme réécrit entièrement un fichier :
fd=open("file" ,O_TRUNC); write(fd, data); close(fd);
Avec les anciens systèmes de fichiers, close(fd); est suffisant pour garantir que le contenu de file sera vidé sur le disque. Même si l'écriture n'est pas à proprement parler transactionnelle, il y a très peu de risque de perdre les données si un crash survient après le dossier est fermé.
Si l'écriture échoue (en raison d'erreurs dans le programme, d'erreurs sur le disque, d'une coupure de courant, etc.), la version d'origine et la version la plus récente du fichier peut être perdue ou corrompue. Si d'autres processus accèdent au fichier pendant son écriture, ils verront une version corrompue. Et si d'autres processus ont le fichier ouvert et ne s'attendent pas à ce que son contenu change (par exemple, une bibliothèque partagée mappée dans plusieurs programmes en cours d'exécution), ils peuvent planter.
Pour éviter ces problèmes, certains programmeurs évitent d'utiliser O_TRUNC du tout. Au lieu de cela, ils peuvent écrire dans un nouveau fichier, le fermer, puis le renommer par-dessus l'ancien :
fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");
Sous les systèmes de fichiers sans allocation retardée, cela est suffisant pour éviter les problèmes potentiels de corruption et de plantage décrits ci-dessus :puisque rename() est une opération atomique, elle ne sera pas interrompue par un crash; et les programmes en cours d'exécution continueront à faire référence à l'ancienne version, désormais non liée, du file tant qu'ils ont un filehandle ouvert. Mais comme l'allocation retardée d'ext4 peut retarder et réorganiser les écritures, le rename("newfile","file") peut être effectué avant le contenu de newfile sont en fait écrits sur le disque, ce qui ouvre le problème des processus parallèles obtenant de mauvaises versions de file tout recommencer.
Pour atténuer cela, le noyau Linux (depuis la version 2.6.30) tente de détecter ces cas de code courants et force les fichiers en question à être alloués immédiatement. Cela réduit, mais n'empêche pas, le risque de perte de données, et cela n'aide en rien avec les nouveaux fichiers. Si vous êtes un développeur, veuillez prendre note :uniquement le moyen de garantir que les données sont écrites sur le disque immédiatement est d'appeler fsync() de manière appropriée.
Sous-répertoires illimités
Ext3 était limité à un total de 32 000 sous-répertoires; ext4 permet un nombre illimité. À partir du noyau 2.6.23, ext4 utilise les indices HTree pour atténuer la perte de performances avec un grand nombre de sous-répertoires.
Somme de contrôle du journal
Ext3 n'a pas effectué la somme de contrôle de ses journaux, ce qui a posé des problèmes pour les périphériques de disque ou de contrôleur avec leurs propres caches, en dehors du contrôle direct du noyau. Si un contrôleur ou un disque avec son propre cache écrivait dans le désordre, cela pourrait casser l'ordre des transactions de journalisation d'ext3, corrompant potentiellement les fichiers écrits pendant (ou pendant un certain temps avant) un plantage.
En théorie, ce problème est résolu par l'utilisation de barrières en écriture - lors du montage du système de fichiers, vous définissez barrier=1 dans les options de montage, et l'appareil respectera alors fsync() crie jusqu'au métal. En pratique, il a été découvert que les périphériques de stockage et les contrôleurs ne le font souvent pas respectez les barrières en écriture, ce qui améliore les performances (et les points de repère, lorsqu'ils sont comparés à leurs concurrents), mais ouvre la possibilité d'une corruption des données qui aurait dû être évitée.
La somme de contrôle du journal permet au système de fichiers de se rendre compte que certaines de ses entrées sont invalides ou hors service lors du premier montage après un crash. Cela évite ainsi l'erreur consistant à annuler des entrées de journal partielles ou dans le désordre et à endommager davantage le système de fichiers, même si les périphériques de stockage mentent et ne respectent pas les barrières.
Vérifications rapides du système de fichiers
Sous ext3, l'ensemble du système de fichiers, y compris les fichiers supprimés et vides, nécessitait une vérification lorsque fsck est invoqué. En revanche, ext4 marque les blocs et sections non alloués de la table d'inodes en tant que tels, permettant à fsck pour les ignorer complètement. Cela réduit considérablement le temps d'exécution de fsck sur la plupart des systèmes de fichiers et a été implémenté depuis le noyau 2.6.24.
Horodatages améliorés
Ext3 offrait des horodatages granulaires à une seconde. Bien que suffisantes pour la plupart des utilisations, les applications critiques recherchent souvent un contrôle du temps beaucoup plus strict. Ext4 se rend disponible pour ces applications d'entreprise, scientifiques et critiques en offrant des horodatages en nanosecondes.
Les systèmes de fichiers Ext3 ne fournissaient pas non plus suffisamment de bits pour stocker les dates au-delà du 18 janvier 2038. Ext4 ajoute ici deux bits supplémentaires, prolongeant l'époque Unix de 408 ans supplémentaires. Si vous lisez ceci en 2446 après JC, vous avez, espérons-le, déjà migré vers un meilleur système de fichiers, mais cela me rendra très, très heureux à titre posthume si vous mesurez toujours le temps depuis UTC 00:00, le 1er janvier 1970.
Défragmentation en ligne
Ni ext2 ni ext3 ne prenaient directement en charge la défragmentation en ligne, c'est-à-dire la défragmentation du système de fichiers lors du montage. Ext2 avait un utilitaire inclus, e2defrag , qui faisait ce que son nom l'indique, mais il devait être exécuté hors ligne alors que le système de fichiers n'était pas monté. (Ceci est, évidemment, particulièrement problématique pour un système de fichiers racine.) La situation était encore pire dans ext3, même si ext3 était beaucoup moins susceptible de souffrir d'une fragmentation sévère que ext2, exécutant e2defrag contre un système de fichiers ext3 pourrait entraîner une corruption catastrophique et une perte de données.
Bien qu'ext3 ait été initialement considéré comme "non affecté par la fragmentation", les processus qui utilisent des processus d'écriture massivement parallèles dans le même fichier (par exemple, BitTorrent) ont clairement indiqué que ce n'était pas tout à fait le cas. Plusieurs hacks et solutions de contournement de l'espace utilisateur, tels que Shake, ont résolu ce problème d'une manière ou d'une autre, mais ils étaient plus lents et, à bien des égards, moins satisfaisants qu'un véritable processus de défragmentation au niveau du noyau, compatible avec le système de fichiers.
Ext4 résout ce problème de front avec e4defrag , un utilitaire de défragmentation en ligne, en mode noyau, sensible au système de fichiers, au niveau des blocs et de l'étendue.
Développement ext4 en cours
Ext4 est, comme les Monty Python victime de la peste a dit un jour, "pas encore tout à fait mort!" Bien que son développeur principal le considère comme un simple palliatif sur la voie d'un véritable système de fichiers de nouvelle génération, aucun des candidats probables ne sera prêt (en raison de problèmes techniques ou de licence) pour un déploiement en tant que système de fichiers racine avant un certain temps encore. /P>
Quelques fonctionnalités clés sont encore en cours de développement dans les futures versions d'ext4, notamment la somme de contrôle des métadonnées, la prise en charge des quotas de première classe et les grands blocs d'allocation.
Somme de contrôle des métadonnées
Étant donné que ext4 a des superblocs redondants, la somme de contrôle des métadonnées qu'ils contiennent offre au système de fichiers un moyen de déterminer par lui-même si le superbloc principal est corrompu et doit utiliser un autre. Il est possible de récupérer d'un superbloc corrompu sans somme de contrôle, mais l'utilisateur doit d'abord se rendre compte qu'il était corrompu, puis essayez de monter manuellement le système de fichiers à l'aide d'un autre. Étant donné que le montage d'un système de fichiers en lecture-écriture avec un superbloc principal corrompu peut, dans certains cas, causer des dommages supplémentaires, ce n'est pas une solution suffisante, même avec un utilisateur suffisamment expérimenté !
Comparé à la somme de contrôle par bloc extrêmement robuste offerte par les systèmes de fichiers de nouvelle génération tels que btrfs ou zfs, la somme de contrôle des métadonnées d'ext4 est une fonctionnalité assez faible. Mais c'est bien mieux que rien.
Bien que cela sonne comme une évidence - oui, somme de contrôle TOUTES LES CHOSES ! - il existe des défis importants pour verrouiller les sommes de contrôle dans un système de fichiers après coup ; voir le document de conception pour les détails concrets.
Prise en charge des quotas de première classe
Attendez, les quotas ? ! Nous les avons depuis les jours ext2 ! Oui, mais ils ont toujours été une réflexion après coup, et ils ont toujours été un peu nuls. Cela ne vaut probablement pas la peine d'entrer dans les détails poilus ici, mais le document de conception explique comment les quotas seront déplacés de l'espace utilisateur vers le noyau et appliqués de manière plus correcte et plus performante.
Grands blocs d'allocation
Au fil du temps, ces systèmes de stockage embêtants deviennent de plus en plus gros. Avec certains disques SSD utilisant déjà des tailles de blocs matériels 8K, la limitation actuelle d'ext4 aux blocs 4K devient de plus en plus restrictive. Des blocs de stockage plus volumineux peuvent réduire la fragmentation et augmenter considérablement les performances, au prix d'une augmentation de l'espace "inutilisé" (l'espace restant lorsque vous n'avez besoin que d'une partie d'un bloc pour stocker un fichier ou le dernier élément d'un fichier).
Vous pouvez voir les détails poilus dans le document de conception.
Limites pratiques d'ext4
Ext4 est un système de fichiers robuste et stable, et c'est ce que la plupart des gens devraient probablement utiliser comme système de fichiers racine en 2018. Mais il ne peut pas tout gérer. Parlons brièvement de certaines des choses que vous ne devriez pas attendre d'ext4, maintenant ou probablement dans le futur.
Bien qu'ext4 puisse traiter jusqu'à 1 EiB (équivalent à 1 000 000 Tio) de données, vous êtes vraiment, vraiment ne devrait pas essayer de le faire. Il y a des problèmes d'échelle au-delà du simple fait de pouvoir se souvenir des adresses de beaucoup plus de blocs, et ext4 n'évolue pas (et ne le sera probablement jamais) bien au-delà de 50 à 100 Tio de données.
Ext4 ne fait pas non plus assez pour garantir l'intégrité de vos données. Aussi grand que soit le progrès de la journalisation dans les jours ext3, il ne couvre pas la plupart des causes courantes de corruption des données. Si les données sont corrompues alors qu'elles sont déjà sur le disque (par un matériel défectueux, l'impact des rayons cosmiques (oui, vraiment) ou une simple dégradation des données au fil du temps), ext4 n'a aucun moyen de détecter ou de réparer une telle corruption.
S'appuyant sur les deux derniers éléments, ext4 n'est qu'un pur système de fichiers , et non un gestionnaire de volume de stockage. Cela signifie que même si vous avez plusieurs disques - et donc la parité ou la redondance, dont vous pourriez théoriquement récupérer des données corrompues - ext4 n'a aucun moyen de le savoir ou de l'utiliser à votre avantage. Alors que c'est théoriquement possible séparer un système de fichiers et un système de gestion de volume de stockage en couches discrètes sans perdre les fonctionnalités de détection et de réparation automatiques de la corruption, ce n'est pas ainsi que les systèmes de stockage actuels sont conçus, et cela présenterait des défis importants pour les nouvelles conceptions.
Systèmes de fichiers alternatifs
Avant de commencer, un mot d'avertissement :soyez très soyez prudent avec tout autre système de fichiers qui n'est pas intégré à et directement pris en charge dans le cadre du noyau principal de votre distribution !
Même si un système de fichiers est sûr , l'utiliser comme système de fichiers racine peut être absolument terrifiant en cas de problème lors d'une mise à niveau du noyau. Si vous n'êtes pas extrêmement à l'aise avec l'idée de démarrer à partir d'un support alternatif et de fouiller manuellement et patiemment les modules du noyau, les configurations grub et DKMS à partir d'un chroot... ne sortez pas de la réservation avec le système de fichiers racine sur un système qui compte pour vous.
Il peut y avoir de bonnes raisons d'utiliser un système de fichiers que votre distribution ne prend pas directement en charge, mais si c'est le cas, je vous recommande fortement de le monter après le système est opérationnel et utilisable. (Par exemple, vous pouvez avoir un système de fichiers racine ext4, mais stocker la plupart de vos données sur un pool zfs ou btrfs.)
XFS
XFS est à peu près aussi important qu'un système de fichiers non-ext sous Linux. Il s'agit d'un système de fichiers journalisé 64 bits qui a été intégré au noyau Linux depuis 2001 et offre des performances élevées pour les systèmes de fichiers volumineux et des degrés élevés de simultanéité (c'est-à-dire un très grand nombre de processus écrivant tous simultanément sur le système de fichiers).
XFS est devenu le système de fichiers par défaut pour Red Hat Enterprise Linux, à partir de RHEL 7. Il présente encore quelques inconvénients pour les utilisateurs à domicile ou les petites entreprises, notamment, il est très pénible de redimensionner un système de fichiers XFS existant, au point qu'il en fait généralement plus. sens d'en créer un autre et de copier vos données dessus.
Bien que XFS soit stable et performant, il n'y a pas assez de différence concrète d'utilisation finale entre lui et ext4 pour recommander son utilisation partout où ce n'est pas la valeur par défaut (par exemple, RHEL7) à moins que il résout un problème spécifique que vous rencontrez avec ext4, tel que les systèmes de fichiers de capacité> 50 Tio.
XFS n'est en aucun cas un système de fichiers "de nouvelle génération" comme le sont ZFS, btrfs ou même WAFL (un système de fichiers SAN propriétaire). Comme ext4, il devrait très probablement être considéré comme un palliatif sur le chemin vers quelque chose de mieux.
ZFS
ZFS a été développé par Sun Microsystems et nommé d'après le zettaoctet, qui équivaut à 1 000 milliards de gigaoctets, car il pourrait théoriquement s'adresser à des systèmes de stockage de cette taille.
Véritable système de fichiers de nouvelle génération, ZFS offre la gestion du volume (la possibilité d'adresser plusieurs périphériques de stockage individuels dans un seul système de fichiers), la somme de contrôle cryptographique au niveau des blocs (permettant la détection de la corruption des données avec un taux de précision extrêmement élevé), la réparation automatique de la corruption (où un stockage redondant ou à parité est disponible), une réplication incrémentielle asynchrone rapide, une compression en ligne, etc. Beaucoup plus.
Le plus gros problème avec ZFS, du point de vue d'un utilisateur Linux, est la licence. ZFS était sous licence CDDL, qui est une licence semi-permissive qui entre en conflit avec la GPL. Il y a beaucoup de controverse sur les implications de l'utilisation de ZFS avec le noyau Linux, avec des opinions allant de "c'est une violation de la GPL" à "c'est une violation de la CDDL" à "c'est parfaitement bien, cela n'a tout simplement pas été testé devant les tribunaux. " Plus particulièrement, Canonical a inclus le code ZFS en ligne dans ses noyaux par défaut depuis 2016 sans contestation judiciaire jusqu'à présent.
À l'heure actuelle, même en tant que très Utilisateur passionné de ZFS moi-même, je ne recommanderais pas ZFS comme système de fichiers Linux racine. Si vous souhaitez tirer parti des avantages de ZFS sous Linux, configurez un petit système de fichiers racine sur ext4, puis placez ZFS sur votre stockage restant et placez-y des données, des applications, tout ce que vous voulez, mais gardez root sur ext4, jusqu'à ce que votre distribution explicitement
btrfs
Btrfs - abréviation de B-Tree Filesystem, et généralement prononcé "beurre" - a été annoncé par Chris Mason en 2007 pendant son mandat chez Oracle. Btrfs vise la plupart des mêmes objectifs que ZFS, offrant la gestion de plusieurs appareils, la somme de contrôle par bloc, la réplication asynchrone, la compression en ligne, etc.
Depuis 2018, btrfs est raisonnablement stable et utilisable comme système de fichiers standard à disque unique, mais ne devrait probablement pas être utilisé comme gestionnaire de volume. Il souffre de problèmes de performances importants par rapport à ext4, XFS ou ZFS dans de nombreux cas d'utilisation courants, et ses fonctionnalités de nouvelle génération - réplication, topologies à plusieurs disques et gestion des instantanés - peuvent être assez boguées, avec des résultats allant de performances catastrophiquement réduites à la perte de données réelle.
Le statut actuel de btrfs est controversé; SUSE Enterprise Linux l'a adopté comme système de fichiers par défaut en 2015, alors que Red Hat a annoncé qu'il ne prendrait plus en charge btrfs à partir de RHEL 7.4 en 2017. Il convient probablement de noter que la production, les déploiements pris en charge de btrfs l'utilisent comme système de fichiers à disque unique, pas en tant que gestionnaire de volumes multidisques à la ZFS, même Synology, qui utilise btrfs sur ses appareils de stockage, mais le superpose au RAID du noyau Linux conventionnel (mdraid) pour gérer les disques.