Ce qui rend ext4 différent

L'amélioration essentielle réside dans la manière dont ext4 suit les fichiers sur le disque. ext2 et ext3 utilisaient une block map : une liste de tous les blocs individuels qu'un fichier occupe. Pour les gros fichiers, cette liste devient longue, ce qui coûte des métadonnées et du temps. ext4 utilise à la place des extents : des séquences contiguës de blocs que vous enregistrez comme un tout. Un fichier de 100 Mo se décrit alors non pas avec des dizaines de milliers de références de blocs séparées, mais avec une poignée de références d'extents. Cela apporte un gain surtout lors de la lecture et de l'écriture de gros fichiers.

De plus, ext4 enregistre les timestamps avec une précision à la nanoseconde, là où ext3 restait bloqué à la seconde. Cela semble être un détail, mais pour la journalisation d'audit et les applications qui nécessitent un enregistrement temporel exact, la différence entre secondes et nanosecondes est la différence entre une suspicion et une preuve.

Journaling : le garde-fou d'ext4

ext4 hérite du mécanisme de journal d'ext3. Le principe : avant que le système de fichiers ne modifie les métadonnées, il écrit d'abord cette modification dans un journal — le journal. Ce n'est qu'ensuite qu'il exécute réellement la modification. Si le système meurt en cours de route à cause d'une panne de courant ou d'un kernel panic, le système de fichiers peut, lors du montage suivant, rembobiner le journal et restaurer les métadonnées dans un état cohérent. Sans journal, il faudrait après chaque crash lancer un `fsck` complet et espérer que rien n'a été perdu.

ext4 connaît trois modes de journal, chacun représentant un compromis différent entre vitesse et sécurité :

• `writeback` journalise uniquement les métadonnées, pas le contenu des fichiers. Rapide, mais après un crash, un fichier peut contenir des métadonnées qui référencent des données jamais écrites.
• `ordered` (le mode par défaut) journalise également uniquement les métadonnées, mais impose que les blocs de données aillent sur le disque avant les métadonnées correspondantes. Un fichier qui apparaît après un crash ne contient alors pas de déchets.
• `journal` écrit toutes les données d'abord dans le journal, puis seulement à leur emplacement définitif. Le plus sûr, mais aussi le plus lent, car chaque opération d'écriture se produit deux fois.

Le mode `ordered` est le bon choix pour la plupart des charges de travail : la sécurité de métadonnées cohérentes sans les coûts de performance d'un journaling complet. Pour les bases de données qui ont leur propre comportement transactionnel, `writeback` peut être une option — mais seulement si vous savez ce que vous sacrifiez.

Les limites d'ext4

ext4 prend en charge des volumes jusqu'à 1 exbioctet (Eio) et des fichiers individuels jusqu'à 16 tébioctets (Tio), selon les spécifications maintenues par Oracle. Ces limites dépassent en pratique de loin ce que vous placez sur un seul système de fichiers — la plupart des serveurs fonctionnent avec des volumes de quelques téraoctets.

Ce qu'ext4 n'a pas, c'est le copy-on-write. Des systèmes de fichiers comme Btrfs et ZFS n'écrivent jamais les données par-dessus les blocs existants, mais vers de nouveaux blocs, puis ne basculent qu'ensuite. Cela rend possibles les snapshots, la compression intégrée et le contrôle par somme de contrôle sur tout le chemin des données. ext4 n'a rien de tout cela. Si vous voulez un snapshot d'un volume ext4, vous devez le résoudre à un autre niveau — avec des snapshots LVM, ou avec un outil de sauvegarde qui fonctionne au niveau des fichiers.

Cela peut sembler un manque, mais c'est aussi un choix pour la simplicité. Les systèmes de fichiers copy-on-write sont plus complexes, consomment plus de mémoire et ont une courbe d'apprentissage plus longue. Sur un serveur standard où vous voulez simplement un système de fichiers fiable qui ne réserve pas de surprises, cette complexité n'est souvent pas nécessaire.

Configurer un volume ext4

Les étapes ci-dessous vous mènent d'une partition nue à un volume ext4 monté, automatiquement disponible à chaque redémarrage.

1. Identifiez le bon disque lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT Cela affiche tous les disques et partitions avec leur système de fichiers actuel. Notez le nom de la partition que vous voulez formater — par exemple `/dev/sdb1`. Vérifiez bien que vous avez le bon disque. Formater un mauvais device signifie une perte de données garantie, et il n'y a pas d'annulation possible.

2. Créez le système de fichiers ext4 sudo mkfs.ext4 /dev/sdb1 Cette commande formate la partition en ext4. Ajoutez `-L datavolume` pour donner un label — pratique si vous gérez plusieurs volumes plus tard et ne voulez pas deviner quel disque est lequel. La commande demande une confirmation si le device contient déjà un système de fichiers. Lisez ce message, tapez `y`, et c'est seulement alors que quelque chose se produit.

3. Créez un point de montage sudo mkdir -p /mnt/data C'est le répertoire où le système de fichiers deviendra visible. Choisissez un nom qui décrit ce qu'il contiendra. Un point de montage comme `/mnt/backup` vous dira encore dans trois mois ce qui est censé se trouver sur ce disque ; `/mnt/data1`, non.

4. Montez le système de fichiers sudo mount /dev/sdb1 /mnt/data La partition est maintenant accessible via `/mnt/data`. Vérifiez avec `df -h /mnt/data` que le volume est correctement monté et quelle est l'espace disponible.

5. Gérez le montage au démarrage

echo "UUID=$(sudo blkid -s UUID -o value /dev/sdb1) /mnt/data ext4 defaults,noatime 0 2" | sudo tee -a /etc/fstab

Ceci ajoute une ligne à `/etc/fstab`, le fichier qui détermine quels systèmes de fichiers sont montés au démarrage. L'utilisation de l'UUID plutôt que du nom de périphérique est importante : les noms de périphériques comme `/dev/sdb1` peuvent changer si vous ajoutez ou retirez des disques, alors que l'UUID reste lié au système de fichiers lui-même. L'option `noatime` évite que chaque lecture n'écrive une mise à jour d'horodatage — une petite optimisation de performance qui peut être perceptible sur des serveurs chargés.

6. Testez la configuration fstab sudo umount /mnt/data && sudo mount -a Avec `mount -a`, le système lit `/etc/fstab` et monte tout ce qui s'y trouve. Si cette commande se termine sans message d'erreur, votre configuration est correcte. Une erreur dans `/etc/fstab` peut empêcher le système de démarrer au prochain redémarrage — c'est pourquoi vous testez maintenant, et non lors d'un redémarrage.

Vérification

Vérifiez que le système de fichiers fonctionne correctement :

df -h /mnt/data
sudo tune2fs -l /dev/sdb1 | grep "Filesystem features"

La première commande affiche le volume monté avec l'espace disponible. La seconde affiche les caractéristiques actives du système de fichiers — vous devriez voir notamment `extents`, `has_journal` et `flex_bg` dans la liste. Si `has_journal` manque, le volume fonctionne sans journal et un crash vous sépare d'un système de fichiers incohérent.

Problèmes courants

Le système ne démarre pas après une modification de fstab Vous avez fait une erreur dans `/etc/fstab`. Démarrez depuis une clé USB live, montez la partition racine et supprimez ou corrigez la ligne erronée. Mieux vaut prévenir : après chaque modification de fstab, exécutez `sudo mount -a` et vérifiez s'il y a des messages d'erreur.

Les fichiers sont lents à ouvrir après un crash Le journal a été rejoué et le système de fichiers est cohérent, mais le cache de blocs est vide. C'est normal et cela se résorbe en quelques minutes à mesure que le système recharge les données en mémoire.

`mkfs.ext4` refuse de s'exécuter sur une partition marquée comme swap Vous devez d'abord désactiver le swap avec `sudo swapoff /dev/sdb1`, repartitionner le disque sans le drapeau swap, puis formater.

Ce pour quoi ext4 est fait, et ce pour quoi il ne l'est pas

Pour la plupart des charges de travail — un serveur web, une base de données avec sa propre stratégie de sauvegarde, un serveur de fichiers pour une petite équipe — ext4 est le choix sûr. Il est largement testé, les outils sont matures et le risque de rencontrer une surprise est faible. C'est plus qu'on ne peut en dire des systèmes de fichiers plus récents, qui doivent encore prouver leur stabilité sur des serveurs de production.

Si vous avez besoin d'instantanés, de compression ou de contrôle par sommes de contrôle, il faut regarder ailleurs. Mais demandez-vous si vous utilisez réellement ces fonctions, ou si elles sonnent bien dans une présentation. Un volume Btrfs avec des instantanés que vous ne restaurez jamais est plus complexe qu'un volume ext4 avec une simple sauvegarde nocturne — et la sauvegarde fonctionne aussi si votre disque tombe physiquement en panne.