ext4

ext4 ( quatrième système de fichiers étendu ) est un système de fichiers journalisé pour Linux , développé comme successeur d' ext3 .

Initialement, ext4 était une série d' extensions rétrocompatibles d'ext3, dont beaucoup avaient été développées par Cluster File Systems pour le système de fichiers Lustre entre 2003 et 2006, afin d'étendre les limites de stockage et d'améliorer les performances. Cependant, d'autres développeurs du noyau Linux s'opposèrent à l'intégration d'extensions à ext3 pour des raisons de stabilité, et proposèrent de créer une branche du code source d'ext3, de la renommer ext4 et d'y effectuer tout le développement, sans impacter les utilisateurs d'ext3. Cette proposition fut acceptée et, le 28 juin 2006, Theodore Ts'o , le mainteneur d'ext3, annonça le nouveau plan de développement d'ext4.

Une version préliminaire de développement d'ext4 a été intégrée à la version 2.6.19 du noyau Linux. Le 11 octobre 2008, les correctifs officialisant la stabilité d'ext4 ont été fusionnés dans les dépôts de code source de Linux 2.6.28 , marquant la fin de la phase de développement et encourageant son adoption. Le noyau 2.6.28, intégrant le système de fichiers ext4, a finalement été publié le 25 décembre 2008 . Le 15 janvier 2010, Google a annoncé la migration de son infrastructure de stockage d' ext2 vers ext4 . Le 14 décembre 2010, Google a également annoncé l'utilisation d'ext4, à la place de YAFFS , sur Android 2.3 .

Ses améliorations par rapport à ext3 incluent une plage de dates qui se termine en 2446 au lieu de 2038 , une précision d'horodatage d'une nanoseconde au lieu d'une seconde et des limites de taille plus élevées.

ext4 est le système de fichiers par défaut de nombreuses distributions Linux, notamment Debian et Ubuntu .

Système de fichiers volumineux

Le système de fichiers ext4 peut théoriquement prendre en charge des volumes jusqu'à 64 Zio et des fichiers individuels jusqu'à 16 Tio avec une taille de bloc standard de 4 Kio , ainsi que des volumes jusqu'à 1 Yio avec des clusters de 64 Kio . Toutefois, une limitation du format d'étendue fait de 1 io la limite pratique. Les limites de taille maximale des fichiers, des répertoires et du système de fichiers augmentent au moins proportionnellement à la taille des blocs du système de fichiers, jusqu'à la taille maximale de 64 Kio disponible sur les processeurs ARM et PowerPC / PowerISA .

Étendue

Les extents remplacent le système de mappage par blocs traditionnel utilisé par ext2 et ext3. Un extent est une plage de blocs physiques contigus, ce qui améliore les performances des fichiers volumineux et réduit la fragmentation. Un seul extent dans ext4 peut mapper jusqu'à 128 Mio d'espace contigu avec une taille de bloc de 4 Kio. Quatre extents peuvent être stockés directement dans l' inode . Lorsqu'un fichier comporte plus de quatre extents, les extents restants sont indexés dans un arbre .

Compatibilité ascendante

ext4 est rétrocompatible avec ext3 et ext2 , ce qui permet de monter ext3 et ext2 en tant qu'ext4. Cela améliorera légèrement les performances, car certaines nouvelles fonctionnalités de l'implémentation ext4 peuvent également être utilisées avec ext3 et ext2, telles que le nouvel algorithme d'allocation de blocs, sans affecter le format sur disque.

ext3 est partiellement compatible avec ext4. En pratique, ext4 ne sera pas monté comme un système de fichiers ext3 par défaut, à moins que certaines nouvelles fonctionnalités ne soient désactivées lors de sa création, telles que ^extent, ^flex_bg, ^huge_file, ^uninit_bg, ^dir_nlink, et ^extra_isize.

Pré-allocation persistante

ext4 permet de pré-allouer de l'espace disque pour un fichier. Sur la plupart des systèmes de fichiers, cela consiste à écrire des zéros dans le fichier lors de sa création. Avec ext4 (et certains autres systèmes de fichiers comme XFS ) fallocate(), un nouvel appel système du noyau Linux permet de le faire. L'espace alloué est garanti et généralement contigu. Cette fonctionnalité trouve des applications dans le streaming multimédia et les bases de données.

Attribution retardée

ext4 utilise une technique de performance appelée allocation à la vidange , également connue sous le nom d'allocation différée . Autrement dit, ext4 retarde l'allocation des blocs jusqu'à ce que les données soient écrites sur le disque ; contrairement à certains systèmes de fichiers qui allouent les blocs immédiatement, même lorsque les données sont placées dans un cache d'écriture. L'allocation différée améliore les performances et réduit la fragmentation en allouant efficacement de plus grandes quantités de données à la fois.

Nombre illimité de sous-répertoires

ext4 ne limite pas le nombre de sous-répertoires dans un répertoire, hormis la taille intrinsèque du répertoire lui-même. (Avec ext3, un répertoire peut contenir au maximum 32 000 sous-répertoires.) Pour permettre des répertoires plus volumineux tout en maintenant de bonnes performances, ext4, sous Linux 2.6.23 et versions ultérieures, active par défaut les index HTree (une version spécialisée d'un arbre B ). Ceci permet de stocker des répertoires jusqu'à environ 10 à 12 millions d'entrées dans un index HTree à deux niveaux, avec une limite de taille de répertoire de 2 Go pour une taille de bloc de 4 Kio, selon la longueur du nom de fichier. Sous Linux 4.12 et versions ultérieures, cette fonctionnalité a permis l'utilisation d'un index HTree à trois niveaux et la prise en charge de répertoires de plus de 2 Go, autorisant ainsi environ 6 milliards d'entrées dans un seul répertoire.large_dir

Sommes de contrôle du journal

ext4 utilise des sommes de contrôle dans le journal pour améliorer la fiabilité, car ce dernier est l'un des fichiers les plus utilisés du disque. Cette fonctionnalité présente un avantage secondaire : elle permet d'éviter les attentes d'E/S disque pendant la journalisation, améliorant ainsi légèrement les performances. Le calcul des sommes de contrôle du journal s'inspire d'un article de recherche de l' Université du Wisconsin , intitulé « IRON File Systems » [ avec des modifications apportées à l'implémentation des transactions composées effectuées par le système de fichiers IRON (proposé initialement par Sam Naghshineh lors du sommet Red Hat).

Somme de contrôle des métadonnées

La prise en charge des sommes de contrôle de métadonnées a été ajoutée dans le noyau Linux version 3.5, publié en 2012. De nombreuses structures de données ont été modifiées pour ajouter les sommes de contrôle CRC-32C, mais certaines ne stockent que les 16 bits de poids faible de la somme de contrôle 32 bits, faute d'espace suffisant pour les 4 octets réservés. La conversion sur place peut être effectuée à l'aide de tune2fs -O metadata_csum .

Vérification plus rapide du système de fichiers

Dans ext4, les groupes de blocs non alloués et les sections de la table d'inodes sont marqués comme tels. Cela permet à e2fsck de les ignorer complètement et réduit considérablement le temps d'analyse du système de fichiers. Linux 2.6.24 implémente cette fonctionnalité.

allocateur multibloc

Lorsqu'ext3 ajoute des données à un fichier, il appelle l'allocateur de blocs une fois par bloc. Par conséquent, en cas d'écritures simultanées par plusieurs utilisateurs, les fichiers peuvent facilement se fragmenter sur le disque. En revanche, ext4 utilise l'allocation différée, ce qui lui permet de mettre les données en mémoire tampon et d'allouer des groupes de blocs. Ainsi, l'allocateur multiblocs peut optimiser l'allocation contiguë des fichiers sur le disque. Il peut également être utilisé lorsque les fichiers sont ouverts en mode O_DIRECT. Cette fonctionnalité est indépendante du format du disque.

Horodatage amélioré

Avec l'augmentation générale de la vitesse des ordinateurs et l'utilisation croissante de Linux pour les applications critiques , la granularité des horodatages à la seconde devient insuffisante. Pour pallier ce problème, ext4 propose des horodatages mesurés en nanosecondes . De plus, deux bits du champ d'horodatage étendu sont ajoutés aux bits de poids fort du champ des secondes afin de repousser le problème de l'année 2038 de 408 ans supplémentaires.

ext4 prend également en charge les horodatages de création. Cependant, comme le souligne Theodore Ts'o , s'il est aisé d'ajouter un champ de date de création supplémentaire à l' inode (activant ainsi techniquement la prise en charge de ces horodatages dans ext4), il est plus complexe de modifier ou d'ajouter les appels système nécessaires , tels que `stat()` (ce qui nécessiterait probablement une nouvelle version) et les différentes bibliothèques qui en dépendent (comme glibc ). Ces modifications exigeront la coordination de nombreux projets. Par conséquent, la date de création stockée par ext4 n'est actuellement accessible aux programmes utilisateurs sous Linux que via l' statx()API.

quotas du projet

La prise en charge des quotas de projet a été ajoutée au noyau Linux 4.4 le 8 janvier 2016. Cette fonctionnalité permet d'attribuer des limites de quota disque à un identifiant de projet spécifique. L'identifiant de projet d'un fichier est un nombre de 32 bits stocké dans chaque fichier et hérité par tous les fichiers et sous-répertoires créés sous un répertoire parent possédant cet identifiant. Cela permet d'attribuer des limites de quota à une arborescence de sous-répertoires particulière, indépendamment des permissions d'accès au fichier, telles que les quotas utilisateur et de projet qui dépendent de l'UID et du GID. Bien que similaire à un quota de répertoire, la principale différence réside dans le fait qu'un même identifiant de projet peut être attribué à plusieurs répertoires de premier niveau et que la hiérarchie n'est pas stricte.

Chiffrement transparent

La prise en charge du chiffrement transparent a été ajoutée dans le noyau Linux 4.1 en juin 2015.

Initialisation paresseuse

La fonctionnalité lazyinit permet le nettoyage des tables d'inodes en arrière-plan, accélérant ainsi l'initialisation lors de la création d'un nouveau système de fichiers ext4. Elle est disponible depuis 2010 dans le noyau Linux version 2.6.37.

Écrire les barrières

ext4 active par défaut les barrières d'écriture. Cela garantit que les métadonnées du système de fichiers sont correctement écrites et ordonnées sur le disque, même en cas de coupure de courant des caches d'écriture. Cette activation a un impact sur les performances, notamment pour les applications qui utilisent intensivement fsync ou qui créent et suppriment de nombreux petits fichiers. Pour les disques dotés d'un cache d'écriture alimenté par batterie, la désactivation des barrières (option « barrier=0 ») peut améliorer les performances sans risque.

En 2008, Theodore Ts'o , principal développeur des systèmes de fichiers ext3 et ext4, a déclaré que malgré des améliorations par rapport à ext3, ext4 ne constituait pas une avancée majeure, car il reposait sur une technologie plus ancienne. Ts'o a alors indiqué que Btrfs pourrait représenter une meilleure orientation, car « il offre des améliorations en termes d'évolutivité, de fiabilité et de facilité de gestion » . Btrfs partageait également « un certain nombre d'idées de conception communes avec reiser3 / 4 », ce qui le rendait attractif à l'époque . Cependant, Ts'o et de nombreux contributeurs d' IBM , Google , SuSE , Huawei et d'autres organisations ont continué à maintenir et à améliorer ext4 en y intégrant de nouvelles fonctionnalités telles que le chiffrement des fichiers, les sommes de contrôle des métadonnées et la prise en charge des noms de fichiers insensibles à la casse.

Le système de fichiers ext4 ne prend pas en charge l' attribut de suppression sécurisée , qui est censé écraser les fichiers lors de leur suppression. Un correctif visant à implémenter la suppression sécurisée a été proposé en 2011, mais n'a pas résolu le problème de la présence de données sensibles dans le journal du système de fichiers.

L'allocation différée modifiant le comportement d'ext3 sur lequel les programmeurs s'appuyaient, cette fonctionnalité présente un risque accru de perte de données en cas de panne système ou de coupure de courant avant que toutes les données n'aient été écrites sur le disque. C'est pourquoi, à partir du noyau Linux 2.6.30, ext4 gère automatiquement ces cas, comme le faisait ext3.

Le scénario typique dans lequel cela pourrait se produire est celui d'un programme remplaçant le contenu d'un fichier sans forcer une écriture sur le disque avec fsync . Il existe deux manières courantes de remplacer le contenu d'un fichier sur les systèmes Unix :

• fd=open("file", O_TRUNC); write(fd, data); close(fd);

Dans ce cas, un fichier existant est tronqué à son ouverture (en raison d' O_TRUNCun indicateur), puis de nouvelles données sont écrites. L'écriture pouvant prendre un certain temps, il existe un risque de perte de données, même avec ext3, bien que généralement très faible. Cependant, comme ext4 peut retarder l'écriture des données pendant une période prolongée, ce risque est beaucoup plus important.

Plusieurs problèmes peuvent survenir :

1. Si l'écriture échoue (ce qui peut être dû à des erreurs dans le programme d'écriture ou à des facteurs externes comme un disque plein), alors la version originale et la nouvelle version du fichier seront perdues, et le fichier risque d'être corrompu car seule une partie de celui-ci aura été écrite.
2. Si d'autres processus accèdent au fichier pendant son écriture, ils verront une version corrompue.
3. Si d'autres processus ont le fichier ouvert et ne s'attendent pas à ce que son contenu soit modifié, ces processus risquent de planter. Un exemple notable est celui d'un fichier de bibliothèque partagée mappé par des programmes en cours d'exécution.

En raison de ces problèmes, l'expression suivante est souvent préférée à la précédente :

• fd=open("file.new"); write(fd, data); close(fd); rename("file.new", "file");

Un nouveau fichier temporaire (« file.new ») est créé et contient initialement le nouveau contenu. Ce nouveau fichier est ensuite renommé en remplacement de l'ancien. Le remplacement de fichiers par cet rename()appel est garanti atomique par les normes POSIX : soit l'ancien fichier est conservé, soit il est écrasé par le nouveau. Le mode de journalisation « ordonné » par défaut d'ext3 garantissant l'écriture des données sur le disque avant les métadonnées, cette technique assure la persistance du contenu, ancien ou nouveau, sur le disque. L'allocation différée d'ext4 remet en cause cette garantie, car l'écriture du fichier peut être retardée considérablement et le renommage est généralement effectué avant que le nouveau contenu n'atteigne le disque.

L'utilisation fsync()plus fréquente de l'option `--noauto_da_alloc` pour réduire les risques liés à ext4 peut entraîner une baisse de performances sur les systèmes de fichiers ext3 montés avec cette data=orderedoption (comportement par défaut sur la plupart des distributions Linux). Étant donné que les deux systèmes de fichiers seront utilisés simultanément pendant un certain temps, cela complique la tâche des développeurs d'applications. En réponse, ext4, dans les noyaux Linux 2.6.30 et versions ultérieures, détecte ces cas fréquents et force l'allocation immédiate des fichiers. Au prix d'une légère perte de performances, ce comportement offre une sémantique similaire au mode ordonné d'ext3 et augmente les chances que les deux versions du fichier survivent à une panne. Ce nouveau comportement est activé par défaut, mais peut être désactivé avec l'option de montage `noauto_da_alloc`.

Les nouveaux correctifs sont devenus partie intégrante du noyau principal 2.6.30, mais diverses distributions ont choisi de les rétroporter vers les versions 2.6.28 ou 2.6.29.

Ces correctifs ne préviennent pas complètement les pertes de données potentielles et n'apportent aucune aide concernant les nouveaux fichiers. La seule façon d'assurer la sécurité est de concevoir et d'utiliser un logiciel qui agit fsync()en conséquence. Les problèmes de performance peuvent être minimisés en limitant les écritures disque critiques qui doivent fsync()être moins fréquentes.

Le système de fichiers virtuel du noyau Linux est un sous-système ou une couche interne au noyau Linux. Il résulte d'une tentative d'intégration de plusieurs systèmes de fichiers au sein d'une structure unique et ordonnée. L'idée principale, qui remonte aux travaux pionniers des employés de Sun Microsystems en 1986 , consiste à extraire la partie du système de fichiers commune à tous les systèmes de fichiers et à placer ce code dans une couche distincte qui fait appel aux systèmes de fichiers concrets sous-jacents pour la gestion effective des données.

Tous les appels système relatifs aux fichiers (ou pseudo-fichiers) sont dirigés vers le système de fichiers virtuel du noyau Linux pour un traitement initial. Ces appels, provenant des processus utilisateur, sont les appels POSIX standard, tels que open`open` read, `open` write, lseek`open`, etc.

Bien que conçu pour Linux et principalement utilisé avec ce système de fichiers, un système de fichiers ext4 peut être accessible via d'autres systèmes d'exploitation grâce à des outils d'interopérabilité.

Windows offre un accès via sa technologie de sous-système Windows pour Linux (WSL). Plus précisément, la deuxième version majeure, WSL 2, est la première à prendre en charge le système de fichiers ext4. Elle a été initialement publiée dans la version Insider Preview de Windows 10 (build 20211) . WSL 2 requiert Windows 10 version 1903 ou ultérieure (build 18362 ou ultérieure) pour les systèmes x64, et version 2004 ou ultérieure (build 19041 ou ultérieure) pour les systèmes ARM64.

Paragon Software propose des produits commerciaux qui offrent un accès complet en lecture/écriture aux systèmes de fichiers Linux ext2/3/4 pour Windows et extFS pour Mac .

Le logiciel libre ext4fuse offre une prise en charge limitée (lecture seule).

Le système de fichiers ext4 divise la partition sur laquelle il se trouve en plus petits fragments appelés blocs (un groupe de secteurs, généralement compris entre 1 et 64 Kio). Par défaut, la taille des blocs est identique à celle des pages (4 Kio), mais elle peut être configurée avec mkfs lors de la création du système de fichiers. Les blocs sont regroupés en ensembles plus importants appelés groupes de blocs.

Il s'agit du cœur du système de fichiers ; il réside dans un seul bloc du disque. Il s'agit généralement du premier élément d'un groupe de blocs, à l'exception du groupe 0, où les premiers octets sont réservés au secteur d'amorçage . Le superbloc est essentiel au système de fichiers ; c'est pourquoi des copies de sauvegarde sont écrites sur les partitions lors de la création du système de fichiers, afin de pouvoir le restaurer en cas de corruption.

Le GDT (Global Data Table) vient en deuxième position après le superbloc. Il stocke les descripteurs de chaque groupe de blocs du système de fichiers et réside sur plusieurs blocs du disque. Chaque GDT a une taille de 64 octets. Cette structure est essentielle au système de fichiers ; c’est pourquoi des sauvegardes redondantes sont stockées sur l’ensemble du système.

Le bitmap des blocs suit l'état d'utilisation de tous les blocs d'un groupe de blocs. Chaque bit du bitmap représente un bloc. Si un bloc est utilisé, son bit correspondant est activé ; sinon, il est désactivé. L'emplacement du bitmap des blocs n'est pas fixe ; sa position est donc stockée dans les descripteurs de groupe de blocs respectifs.

À l'instar du bitmap des blocs, l'emplacement du bitmap des inodes n'est pas fixe ; par conséquent, le descripteur de groupe pointe vers cet emplacement. Le bitmap des inodes permet de suivre l'utilisation des inodes. Chaque bit du bitmap représente un inode. Si un inode est utilisé, le bit correspondant dans le bitmap des inodes est activé ; sinon, il est désactivé.

Chaque groupe de blocs est représenté par son descripteur. Ce dernier contient des informations essentielles telles que le nombre d'inodes libres , le nombre de blocs libres, ainsi que l'emplacement des bitmaps d'inodes et de blocs, et de la table d'inodes du groupe de blocs concerné.

Ext4 a introduit les groupes de blocs flexibles. Dans flex_bg , plusieurs groupes de blocs sont regroupés en un seul groupe de blocs logique. La table de bits des blocs et la table des inodes du premier groupe de blocs sont étendues pour inclure la table de bits et la table des inodes des autres groupes de blocs.