Module Ansible filesystem : créer un système de fichiers Linux

Le module community.general.filesystem crée un système de fichiers sur une partition ou un volume logique : ext4, xfs, btrfs, f2fs, swap. C'est l'étape après la partition (cf. parted ou un LV LVM) et avant le mount. Public visé : intermédiaires Ansible RHEL/Debian, candidats RHCSA. Cette page couvre la création (ext4, xfs), le resize (étendre un fs après agrandissement de la partition), les différences entre fstypes et les pièges idempotence (un fs créé reste créé, on ne le détruit pas par accident).

Ce que vous allez apprendre

• Créer un filesystem ext4 ou xfs sur une partition.
• Choisir entre ext4, xfs, btrfs selon le cas d'usage.
• Étendre un filesystem après agrandissement du device sous-jacent.
• Forcer la création (force: true) sur un device qui contient déjà un fs.
• Diagnostiquer les pièges d'idempotence.

Prérequis

• Collection community.general installée :

  ansible-galaxy collection install community.general

• Outils userspace présents sur le nœud (mkfs.ext4, mkfs.xfs, etc.), installés par défaut sur RHEL et Debian.

• Un device cible : partition (/dev/vdb1), LV (/dev/vg_data/lv_app), ou disque entier.

• Privilèges root (become: true).

Le module ne détruit jamais un fs existant par défaut

Filesystem est protégé contre la destruction accidentelle : si le device contient déjà un fs (même différent du fstype demandé), la task n'écrase pas sauf force: true. C'est volontaire, destruction de données = catastrophe.

Création standard, ext4 ou xfs

Deux paramètres suffisent à décrire l'intention : le type de système de fichiers voulu et le périphérique qui le portera. Tout le reste tient dans ce que le module observe avant d'agir, et c'est ce qui fait sa sûreté : il regarde ce que porte déjà le périphérique et n'écrit que si la situation le justifie. La liste ci-dessous se lit donc comme une table de décision, les quatre cas couvrant l'ensemble des états possibles du périphérique visé.

- name: Créer un fs ext4 sur /dev/vdb1
  community.general.filesystem:
    fstype: ext4
    dev: /dev/vdb1
    state: present

Comportement :

• Si /dev/vdb1 n'a aucun fs → mkfs.ext4 /dev/vdb1 est exécuté, task changed.
• Si /dev/vdb1 a déjà un fs ext4 → task ok (idempotent).
• Si /dev/vdb1 a un autre fs (xfs, btrfs) → task failed sauf si force: true.
• Si /dev/vdb1 n'existe pas → task failed.

Pour xfs :

- name: Créer un fs xfs sur /dev/vg_data/lv_app
  community.general.filesystem:
    fstype: xfs
    dev: /dev/vg_data/lv_app
    state: present

ext4 vs xfs vs btrfs, quel choix

Le choix se joue moins sur les performances brutes que sur ce que le système de fichiers sait faire plus tard, une fois les données en place. La question décisive est presque toujours la même : le volume devra-t-il un jour rétrécir ? Si oui, ext4 reste le seul des trois à le permettre, hors sauvegarde et restauration complète. Sinon, suivre le défaut de la distribution évite les surprises, et c'est xfs sur toute la famille RedHat depuis RHEL 7.

Fstype	Forces	Faiblesses	Quand l'utiliser
ext4	Mature, très large compat, fsck rapide	Pas de checksums	Workloads classiques, SSD systèmes
xfs	Default RHEL 9/10, scale jusqu'à 8 EiB, perf en parallèle	Pas de shrink (extension only)	Stockage de données, workloads I/O parallèles
btrfs	Snapshots natifs, checksums, RAID intégré	Plus complexe, recovery parfois capricieux	Postes de travail (Fedora default), backup
swap	(pas un vrai fs)	Sans objet	Espace de pagination

Glissez pour voir

Sur RHEL 8/9/10, le default est xfs, c'est ce que l'installeur RHEL choisit pour /, /home, /var. Sur Debian/Ubuntu, c'est ext4.

Cas d'usage :

• /, /home sur RHEL → xfs (par cohérence avec l'installeur).
• /, /home sur Debian → ext4.
• /var/lib/postgresql/, /var/lib/mysql/ → xfs (perf I/O parallèles).
• /boot/efi → vfat (ESP doit être FAT).
• Swap → fstype: swap.

Création swap

L'espace de pagination n'est pas un système de fichiers, mais le module le traite comme tel : fstype: swap lance mkswap et prépare le périphérique. Il reste ensuite deux gestes, l'activation immédiate et l'inscription dans la table des montages, sans laquelle rien ne sera repris au prochain démarrage. Les trois tâches ci-dessous couvrent cette chaîne complète, chacune idempotente à sa manière.

- name: Créer un fs swap
  community.general.filesystem:
    fstype: swap
    dev: /dev/vdb2

- name: Activer le swap
  ansible.builtin.command: swapon /dev/vdb2
  args:
    creates: /proc/swaps        # idempotence simple

- name: Ajouter le swap dans /etc/fstab
  ansible.posix.mount:
    src: /dev/vdb2
    path: none
    fstype: swap
    opts: sw
    state: mounted

fstype: swap lance mkswap. Pour activer le swap au boot, l'ajouter dans /etc/fstab via ansible.posix.mount.

Étendre un filesystem (resize)

Cas typique : la partition ou le LV a été agrandi, on veut propager l'agrandissement au filesystem.

Agrandir le volume ne suffit jamais : le système de fichiers ignore l'espace ajouté tant que personne ne le lui dit. Deux modules savent le faire, celui du volume logique et celui-ci, et c'est précisément pourquoi l'exemple désactive explicitement l'option côté volume. Confier l'agrandissement à un seul endroit rend le playbook lisible et évite deux tâches qui se disputent la même opération, dont l'une finira par se plaindre qu'il n'y a plus rien à faire.

# 1. Agrandir le LV
- name: Créer le volume logique lv_app
  community.general.lvol:
    vg: vg_data
    lv: lv_app
    size: 100g
    resizefs: false        # PAS de resize côté lvol : on le fait via filesystem

# 2. Étendre le fs sur le device agrandi
- name: Formater lv_app
  community.general.filesystem:
    fstype: xfs
    dev: /dev/vg_data/lv_app
    resizefs: true

resizefs: true lance la commande appropriée selon le fstype :

• ext4 → resize2fs /dev/... (online si fs monté).
• xfs → xfs_growfs /<mountpoint> (le fs doit être monté pour étendre xfs).
• btrfs → btrfs filesystem resize ....

La contrainte à retenir tient en un mot : xfs s'étend monté, ext4 accepte les deux états. Un playbook qui démonte avant d'agrandir fonctionne donc sur ext4 et échoue sur xfs, ce qui explique l'un des messages d'erreur les plus déroutants du tableau des pièges.

xfs ne se shrink pas

xfs ne supporte pas la réduction. Si vous devez réduire un volume xfs, il faut :

1. Sauvegarder les données.
2. Détruire le fs.
3. Réduire le device (LV ou partition).
4. Recréer le fs.
5. Restaurer les données.

C'est un trade-off xfs vs ext4, ext4 supporte le shrink offline (resize2fs <device> <size> avec fs démonté).

Forcer la création, force: true

Cette option retire le garde-fou décrit plus haut : le module écrase ce qu'il trouve, sans question et sans retour possible. Elle ne se pose donc jamais « au cas où », mais dans des situations où la perte de données est l'intention, et où le contenu du périphérique est connu de celui qui écrit la tâche.

Pour écraser un fs existant (perte de données, assumée) :

- name: Reformatter une partition (perte de données accepté)
  community.general.filesystem:
    fstype: xfs
    dev: /dev/vdb1
    force: true

Trois situations le justifient, et elles ont en commun d'être décidées à l'avance, jamais découvertes en cours de playbook :

• Lab jetable.
• Re-provisionnement complet d'un device après destroy.
• Migration de fstype (rare, généralement migre les données vers un nouveau device).

Pièges courants

Ces six lignes se rangent en trois familles. Les deux premières décrivent un état incompatible avec l'opération demandée, un volume monté qu'on tente de formater, un volume démonté qu'on tente d'agrandir. Les deux suivantes touchent à l'identifiant du système de fichiers, qui change à chaque création et laisse la table des montages en arrière. Les deux dernières sont des questions d'environnement, les outils de formatage absents de la machine et un chemin de périphérique qui varie d'un démarrage à l'autre.

Symptôme	Cause	Solution
device <X> is mounted, not allowed	Device monté, mkfs refuse	Démonter avec ansible.posix.mount: state=unmounted
cannot resize sur xfs démonté	xfs s'étend uniquement online	Monter le fs d'abord puis lancer le resize
wrong fs type, bad option, bad superblock au mount	Fs créé mais corrompu	Re-créer avec force: true puis re-mount
Mauvaise UUID, fstab ne match plus	Re-création du fs change l'UUID	Re-mettre à jour /etc/fstab avec la nouvelle UUID après recréation
mkfs.<fs>: command not found	Outils userspace manquants	dnf install xfsprogs e2fsprogs btrfs-progs selon le fs
Idempotence cassée sur device dynamique	Device path change (LVM, multipath)	Utiliser un identifiant stable (UUID, /dev/disk/by-uuid/...)
Module manquant	Collection community.general non installée	ansible-galaxy collection install community.general

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• community.general.filesystem crée un fs sur un device, pas une partition (utiliser parted avant).
• Default RHEL = xfs, default Debian/Ubuntu = ext4.
• xfs ne shrink pas, choix engageant, à connaître avant de créer.
• resizefs: true étend automatiquement le fs après agrandissement du device.
• force: true écrase un fs existant, destruction de données assumée, à n'utiliser qu'en cas explicite.
• Le module ne démonte pas, c'est à vous de démonter avant si nécessaire.
• Enchaîner toujours partition → filesystem → mount dans un rôle.

Mettre en pratique

Le choix d'un fstype est engageant, et la protection contre l'écrasement ne se comprend bien qu'en la déclenchant. Ce lab vous fait formater deux partitions, l'une en ext4, l'autre en xfs, puis vérifier ce que blkid retourne réellement. Vous provoquez ensuite l'échec attendu en changeant de type sans force: true, avant de forcer la recréation en connaissance de cause.

Lab pratique

Module filesystem : créer un système de fichiers

$ dsoxlab run modules-rhel-filesystem

Environnement : VM·Durée : ~35 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run modules-rhel-filesystem
dsoxlab check modules-rhel-filesystem

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Pour aller plus loin

• Module stat : contrôler l'état réel d'un périphérique avant de le formater.
• Modules assert et fail : transformer ce contrôle en précondition bloquante, avec un message d'erreur clair.
• Écrire ses premiers rôles : ranger la séquence partition, filesystem et montage dans un rôle réutilisable.

×

📖 Voir la documentation →