Utilisation de la commande `mkfs` sous Linux : Guide complet pour formater les disques et les partitions

La commande `mkfs` (make filesystem) est le principal utilitaire Linux pour écrire une structure de système de fichiers sur un périphérique de bloc — qu’il s’agisse d’un disque brut, d’une partition ou d’un volume logique. Elle initialise le superbloc, les tables d’inodes, les groupes de blocs et les structures de journal nécessaires avant que des données puissent être écrites sur ce périphérique.

Avant de toucher à un disque, comprenez ceci : `mkfs` est une opération destructive et irréversible. Elle n’efface pas simplement une entrée de table de partition — elle écrase les métadonnées critiques sur le disque. L’exécuter sur le mauvais périphérique, même brièvement, rend les données existantes irrécupérables sans outils forensiques. Vérifiez votre périphérique cible avec `lsblk` ou `blkid` avant chaque invocation.

Ce que `mkfs` fait réellement en coulisses

Lorsque vous exécutez `mkfs -t ext4 /dev/sdb1`, le noyau ne se contente pas de « formater » la partition au sens Windows du terme. La commande appelle le binaire spécifique au système de fichiers approprié (dans ce cas `mkfs.ext4`, qui est en réalité `mke2fs` avec les paramètres par défaut ext4) et effectue les opérations suivantes :

• Écrit le superbloc et les copies de superbloc de sauvegarde à des décalages fixes de groupe de blocs
• Alloue et initialise la table d’inodes dans tous les groupes de blocs
• Crée la table de descripteurs de groupes de blocs
• Initialise le journal (pour les systèmes de fichiers journalisés comme ext4 et XFS)
• Écrit l’inode du répertoire racine (inode 2 pour ext4)
• Appose un UUID sur le système de fichiers pour une identification persistante

Cette distinction est importante sur les grands disques. Le formatage d’une partition ext4 de 4 To avec une initialisation complète de la table d’inodes peut prendre plusieurs minutes. XFS, en revanche, diffère la majeure partie de ce travail à l’exécution, rendant son `mkfs.xfs` quasi instantané quelle que soit la taille du volume.

Identification du périphérique correct avant le formatage

Ne devinez jamais un nom de périphérique. Utilisez les outils suivants pour associer le matériel physique aux nœuds de périphérique du noyau.

Utilisation de `lsblk`

“`bash

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINT

“`

Exemple de sortie :

“`

NAME SIZE FSTYPE LABEL UUID MOUNTPOINT

sda 100G

├─sda1 20G ext4 a1b2c3d4-… /

└─sda2 80G ext4 e5f6a7b8-… /home

sdb 500G

└─sdb1 500G

“`

Un champ `FSTYPE` vide confirme que `/dev/sdb1` n’a pas de système de fichiers existant — il est sûr de le formater.

Utilisation de `blkid`

“`bash

sudo blkid /dev/sdb1

“`

Si la commande ne retourne aucune sortie, la partition ne contient aucune signature de système de fichiers reconnue. Si elle retourne un type, vous êtes sur le point d’écraser des données existantes.

Utilisation de `fdisk -l`

“`bash

sudo fdisk -l /dev/sdb

“`

Cela révèle les limites des partitions, les types de partitions et si le disque utilise MBR ou GPT. Si `/dev/sdb` n’affiche aucune table de partition, vous devrez peut-être d’abord le partitionner avec `fdisk`, `gdisk` ou `parted` avant d’exécuter `mkfs`.

Syntaxe de base de `mkfs` et modèles d’invocation

La syntaxe canonique est :

“`bash

mkfs -t <filesystem_type> [options] <device>

“`

Cependant, `mkfs` lui-même est un wrapper léger. Chaque type de système de fichiers est livré avec son propre binaire dédié :

Appeler `mkfs -t ext4` et appeler `mkfs.ext4` directement sont fonctionnellement identiques — le premier se résout simplement vers le second. Dans les scripts de production, préférez l’alias explicite (`mkfs.ext4`) pour rendre l’intention sans ambiguïté.

Sélection du type de système de fichiers : comparaison technique

Choisir le mauvais système de fichiers pour une charge de travail est une erreur courante et coûteuse. Le tableau suivant associe les caractéristiques des systèmes de fichiers à des cas d’utilisation réels.

Cas limite critique — la Partition Système EFI : L’ESP doit être formatée en `vfat` (FAT32 spécifiquement). L’utilisation de tout autre système de fichiers empêchera le firmware UEFI de localiser le chargeur d’amorçage. Formatez toujours l’ESP avec :

“`bash

sudo mkfs.vfat -F 32 /dev/sda1

“`

Le flag `-F 32` force explicitement FAT32 plutôt que FAT16, ce qui est important pour les partitions ESP de plus de 32 MiB.

Exemples pratiques de `mkfs` avec des options de niveau production

Exemple 1 : Création d’un système de fichiers ext4 avec des paramètres ajustés

“`bash

sudo mkfs.ext4 -L "data_vol" -m 1 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sdb1

“`

Ce que fait chaque flag :

• `-L "data_vol"` — attribue un label persistant, permettant aux entrées `/etc/fstab` d’utiliser `LABEL=data_vol` au lieu d’un chemin de périphérique brut (plus sûr sur les systèmes où l’ordre d’énumération des périphériques peut changer)
• `-m 1` — réduit le pourcentage de blocs réservés de 5% par défaut à 1% ; sur un volume de données de 2 To, la valeur par défaut gaspille ~100 Go que seul root peut utiliser
• `-E lazy_itable_init=0,lazy_journal_init=0` — force l’initialisation complète de la table d’inodes au moment du formatage plutôt que de la différer en E/S en arrière-plan ; critique pour les serveurs de production où l’initialisation en arrière-plan peut provoquer des pics d’E/S inattendus des heures après le déploiement

Exemple 2 : Création d’un système de fichiers XFS pour un serveur de base de données

“`bash

sudo mkfs.xfs -L "pg_data" -f /dev/sdb1

“`

• `-f` — force la création même si une signature de système de fichiers existante est détectée ; à utiliser uniquement lorsque vous avez confirmé que le périphérique est jetable
• XFS ne prend pas en charge la réduction ; planifiez soigneusement la taille de votre volume avant le formatage

Pour les charges de travail PostgreSQL ou MySQL sur XFS, définissez également l’option de montage `noatime` dans `/etc/fstab` pour éliminer la surcharge d’écriture du temps d’accès aux inodes à chaque opération de lecture.

Exemple 3 : Création d’un système de fichiers Btrfs avec RAID-1 sur deux périphériques

“`bash

sudo mkfs.btrfs -L "btrfs_mirror" -d raid1 -m raid1 /dev/sdb /dev/sdc

“`

Btrfs peut s’étendre sur plusieurs périphériques de bloc nativement. `-d raid1` met en miroir les données ; `-m raid1` met en miroir les métadonnées. C’est une alternative légitime au RAID logiciel mdadm pour les environnements où la fonctionnalité de snapshot et de sous-volume est également nécessaire.

Exemple 4 : Création d’un système de fichiers vFAT pour une clé USB

“`bash

sudo mkfs.vfat -F 32 -n "BACKUP_USB" /dev/sdc1

“`

• `-n "BACKUP_USB"` — définit le label du volume (les labels FAT32 sont limités à 11 caractères, en majuscules)
• `-F 32` — sélectionne explicitement FAT32 plutôt que FAT16

Exemple 5 : Création d’un système de fichiers F2FS sur un SSD

“`bash

sudo mkfs.f2fs -l "ssd_cache" /dev/sdb1

“`

F2FS est spécifiquement conçu pour le stockage flash NAND. Il réduit l’amplification des écritures et gère l’usure au niveau du système de fichiers. Sur les instances d’Hébergement VPS soutenues par un stockage NVMe, F2FS peut surpasser ext4 pour les volumes de cache éphémères avec un fort taux de rotation des écritures.

Formatage d’un disque entier sans table de partition

Dans des scénarios spécifiques — volumes physiques LVM, OSDs Ceph ou appliances de stockage à usage unique — vous pouvez écrire un système de fichiers directement sur un disque entier plutôt que sur une partition :

“`bash

sudo mkfs.ext4 /dev/sdb

“`

Quand c’est approprié :

• Le disque est dédié à un seul usage et la flexibilité des partitions n’est pas nécessaire
• Vous préparez un disque pour LVM (`pvcreate` gère cela différemment, mais le concept est similaire)
• Vous créez une image de système de fichiers en loopback

Quand ce n’est pas approprié :

• Tout disque qui doit démarrer (nécessite une table de partition avec un flag de démarrage)
• Tout disque partagé entre plusieurs systèmes de fichiers ou systèmes d’exploitation
• Les disques sur des systèmes où les règles udev ou les outils d’infrastructure cloud attendent une table de partition

Montage de la partition formatée et persistance

Le formatage crée le système de fichiers ; le montage le rend accessible. Utilisez toujours des références basées sur UUID dans `/etc/fstab` plutôt que des noms de périphériques, car les noms de périphériques (`/dev/sdb1`) ne sont pas garantis d’être stables entre les redémarrages sur les systèmes avec plusieurs disques ou un stockage à connexion à chaud.

“`bash

Create the mount point

sudo mkdir -p /mnt/data_vol

Mount temporarily to verify

sudo mount /dev/sdb1 /mnt/data_vol

Retrieve the UUID

sudo blkid /dev/sdb1

Output: /dev/sdb1: LABEL="data_vol" UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"

Add a persistent, UUID-based fstab entry

echo 'UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /mnt/data_vol ext4 defaults,noatime 0 2' | sudo tee -a /etc/fstab

Validate the fstab entry without rebooting

sudo mount -a

“`

Les `0 2` à la fin de l’entrée fstab contrôlent `dump` (utilitaire de sauvegarde, mettre à 0 pour désactiver) et l’ordre de passage `fsck` (2 signifie vérifier après le système de fichiers racine ; la racine doit être 1).

Vérification de l’intégrité du système de fichiers après le formatage

Ne supposez pas qu’un formatage a réussi sans vérification.

“`bash

Check filesystem type, label, and UUID

lsblk -f /dev/sdb1

For ext4: run e2fsck in read-only check mode

sudo e2fsck -n /dev/sdb1

For XFS: verify the filesystem structure

sudo xfs_repair -n /dev/sdb1

Check available space after mounting

df -hT /mnt/data_vol

“`

Le flag `-n` sur `e2fsck` et `xfs_repair` effectue une vérification à blanc sans modifier le système de fichiers. Il est sûr de l’exécuter sur un système de fichiers monté à des fins de diagnostic, bien qu’une réparation complète nécessite de le démonter d’abord.

Référence des options avancées

Pièges courants et comment les éviter

Formatage d’un système de fichiers monté : Linux ne l’empêchera pas toujours. Exécuter `mkfs` sur une partition montée corrompt immédiatement le système de fichiers et peut provoquer des paniques du noyau. Vérifiez toujours l’état de montage avec `mount | grep /dev/sdb1` avant de continuer.

Épuisement des inodes sur ext4 : Si vous définissez une grande taille de bloc (par exemple, 4096 octets) sur un volume qui stockera des millions de petits fichiers (files d’attente de courrier, caches de session), vous épuiserez les inodes bien avant l’espace disque. Utilisez `-i 4096` ou `-i 2048` pour augmenter la densité des inodes. C’est un problème particulièrement courant sur les serveurs d’Hébergement Email et les serveurs web à fort trafic stockant des fichiers par session.

XFS et la réduction : Les volumes XFS ne peuvent pas être réduits après leur création. Si vous formatez un volume XFS de 2 To et que vous avez besoin de récupérer de l’espace ultérieurement, votre seule option est la sauvegarde, le reformatage et la restauration. Planifiez les tailles de volumes XFS de manière conservatrice ou utilisez le provisionnement fin LVM en dessous.

Alignement des bandes pour RAID et SSD : Le formatage sans spécifier l’alignement des bandes sur un tableau RAID ou un SSD provoque des E/S mal alignées, dégradant significativement les performances. Pour un tableau RAID-5 avec une bande de 512 Ko et 4 disques :

“`bash

sudo mkfs.ext4 -E stride=128,stripe-width=384 /dev/md0

“`

Où `stride = stripe_size / block_size` et `stripe-width = stride * (data_disks)`.

Collisions d’UUID après clonage de disque : Le clonage d’un disque avec `dd` duplique l’UUID du système de fichiers. Deux périphériques avec des UUID identiques provoquent des échecs de montage et une corruption des données. Après le clonage, régénérez l’UUID :

“`bash

sudo tune2fs -U random /dev/sdb1 # ext4

sudo xfs_admin -U generate /dev/sdb1 # XFS

“`

C’est une considération critique lors du déploiement de Serveurs Dédiés à partir d’images disque ou du provisionnement de plusieurs nœuds à partir d’un seul modèle.

Considérations sur les systèmes de fichiers pour les environnements VPS et cloud

Sur les machines virtuelles et les instances cloud, le stockage sous-jacent est souvent un disque virtuel à provisionnement fin soutenu par un système de stockage distribué. Plusieurs décisions `mkfs` deviennent plus impactantes dans ce contexte :

• Support Discard/TRIM : Formatez ext4 avec `-E discard` ou ajoutez l’option de montage `discard` pour activer le TRIM en ligne, qui retourne les blocs libérés au pool de stockage sous-jacent et maintient les performances dans le temps sur les instances VPS avec cPanel soutenues par SSD.
• Mode journal : Pour les applications sensibles à la latence, envisagez le mode journal `data=writeback` dans `/etc/fstab` pour ext4. Cela échange un ordre d’écriture strict contre une latence d’écriture plus faible, acceptable pour les bases de données qui gèrent leurs propres journaux d’écriture anticipée.
• Évitez de formater le swap comme un système de fichiers : Les partitions swap utilisent `mkswap`, pas `mkfs`. Exécuter `mkfs` sur une partition swap détruit la signature swap sans créer un système de fichiers utilisable.

Lors de la gestion du stockage sur les Panneaux de Contrôle VPS, les volumes de disque supplémentaires apparaissent généralement comme des périphériques de bloc non formatés. Le flux de travail est toujours : identifier avec `lsblk`, partitionner si nécessaire avec `fdisk`/`gdisk`, formater avec `mkfs`, monter et persister dans `/etc/fstab`.

Matrice de décision : choisir le bon système de fichiers

Utilisez cette matrice pour sélectionner un système de fichiers en fonction de votre contrainte principale :

Liste de contrôle des points clés techniques

Avant d’exécuter `mkfs` dans n’importe quel environnement, parcourez cette liste de contrôle :

• Confirmez le périphérique cible avec `lsblk -f` et `blkid` — ne vous fiez jamais à la mémoire ou aux suppositions
• Démontez la cible avec `umount /dev/sdXN` et vérifiez avec `mount | grep sdX`
• Sauvegardez toutes les données sur le périphérique ; `mkfs` n’est pas réversible
• Sélectionnez le type de système de fichiers en fonction de la charge de travail (voir la matrice de décision ci-dessus), pas par habitude
• Définissez un label de système de fichiers avec `-L` pour une identification lisible par l’homme dans les journaux et `fstab`
• Réduisez les blocs réservés sur les grands volumes de données (`-m 1` pour ext4) pour récupérer de l’espace utilisable
• Désactivez l’initialisation paresseuse (`-E lazy_itable_init=0`) sur les serveurs de production pour éviter les pics d’E/S après le déploiement
• Utilisez UUID dans `/etc/fstab`, pas les noms de périphériques, pour la persistance du montage
• Validez avec `mount -a` après avoir modifié `/etc/fstab` pour détecter les erreurs avant le redémarrage
• Exécutez `e2fsck -n` ou `xfs_repair -n` après le formatage pour confirmer l’intégrité du système de fichiers
• Régénérez les UUID sur tout disque cloné à partir d’une image modèle

FAQ

Q : Puis-je exécuter `mkfs` sur une partition actuellement montée ?

R : Techniquement, le noyau peut le permettre, mais cela corrompt immédiatement le système de fichiers et peut déclencher des paniques du noyau ou une perte de données. Démontez toujours la partition en premier et confirmez avec `mount | grep <device>` avant d’exécuter `mkfs`.

Q : Quelle est la différence entre `mkfs.ext4` et `mke2fs` ?

R : `mkfs.ext4` est un lien symbolique ou un wrapper qui appelle `mke2fs` avec les paramètres par défaut `-t ext4`. Ils sont fonctionnellement identiques. `mke2fs` est l’outil canonique et accepte toute la gamme des options de création ext2/ext3/ext4.

Q : Pourquoi le formatage d’une grande partition ext4 prend-il autant de temps par rapport à XFS ?

R : ext4 initialise la table d’inodes pour chaque groupe de blocs au moment du formatage (sauf si `lazy_itable_init=1` est défini). Sur un volume de 4 To, cela implique l’écriture de gigaoctets de données de table d’inodes mises à zéro. XFS diffère l’initialisation des structures à l’exécution, permettant à `mkfs.xfs` de se terminer en quelques secondes quelle que soit la taille du volume.

Q : Comment changer un label de système de fichiers après le formatage sans reformater ?

R : Pour ext4, utilisez `sudo tune2fs -L "NewLabel" /dev/sdb1`. Pour XFS, utilisez `sudo xfs_admin -L "NewLabel" /dev/sdb1`. Pour FAT32, utilisez `sudo fatlabel /dev/sdb1 NEWLABEL`. Aucune donnée n’est affectée par le changement de label.

Q : Est-il sûr d’utiliser `mkfs` sur un volume logique LVM ?

R : Oui. Les volumes logiques LVM apparaissent comme des périphériques de bloc (par exemple, `/dev/mapper/vg0-lv_data` ou `/dev/vg0/lv_data`) et sont traités de manière identique aux partitions physiques par `mkfs`. C’est le flux de travail standard pour le stockage Linux en production : créer le LV avec `lvcreate`, formater avec `mkfs`, monter et persister dans `/etc/fstab`.