Avant d’installer Linux : pensez votre partitionnement

Avant d’installer Linux : pensez votre partitionnement

Quand on installe Linux, l’une des décisions les plus faciles à repousser est aussi l’une de celles qu’il est parfois le plus difficile de corriger ensuite :

Comment voulons-nous organiser notre disque ?

La plupart des distributions proposent aujourd’hui des installations automatiques très pratiques.

On choisit le disque.

On clique.

On attend.

Et quelques minutes plus tard, Linux fonctionne.

Pour un ordinateur de bureau classique, c’est parfaitement raisonnable.

Mais il existe une autre approche.

Avant de laisser l’installateur décider à notre place, on peut prendre quelques minutes pour réfléchir à la manière dont nous voulons que notre système évolue dans six mois, deux ans ou même davantage.

C’est précisément ce que nous allons faire ici.

Nous allons prendre un vrai disque comme exemple.

Pas un disque imaginaire.

Pas une configuration théorique sortie d’un manuel.

Notre exemple est un véritable SSD utilisé sur notre machine de laboratoire :

Samsung SSD 980 1TB
931.51 GiB available to the system

├── /        80.00 GiB    ext4
├── /var     50.00 GiB    XFS
├── /home   785.51 GiB    XFS
└── swap     16.00 GiB

Le premier détail intéressant est immédiatement visible :

Un SSD vendu comme « 1 To » n’apparaît pas comme 1 000 GiB dans Linux.

Ce n’est pas une perte mystérieuse d’espace.

Le fabricant utilise des unités décimales pour annoncer la capacité du disque, tandis que les outils Linux affichent très souvent des valeurs en unités binaires comme les GiB.

Notre « 1 To » apparaît donc ici comme environ 931,51 GiB.

Pourquoi ne pas simplement utiliser une seule partition ?

C’est probablement la première question.

Et la réponse est simple :

On peut.

Une installation Linux avec une seule grande partition racine peut fonctionner parfaitement bien.

Dans beaucoup de cas, c’est même la solution la plus simple.

Le partitionnement manuel n’est pas présenté par Ubuntu comme quelque chose que tout le monde doit utiliser : la documentation actuelle réserve cette approche aux utilisateurs qui souhaitent une configuration spécifique et qui sont à l’aise avec les outils de partitionnement.

La question n’est donc pas :

« Combien de partitions faut-il obligatoirement pour installer Linux ? »

La meilleure question est plutôt :

« Quelles parties de mon système est-ce que je veux pouvoir isoler ? »

Une partition, c’est quoi au juste ?

Avant de parler de /, /var ou /home, il faut distinguer deux choses que l’on mélange souvent.

Une partition est une portion du périphérique de stockage.

Un système de fichiers est la manière dont cette portion est organisée pour stocker les fichiers et les répertoires.

On peut donc avoir :

Physical disk
      ↓
partition
      ↓
filesystem
      ↓
mount point

Dans notre exemple, nous avons par exemple :

/dev/nvme1n1p1
      ↓
      ext4
      ↓
      /

et :

/dev/nvme1n1p2
      ↓
      XFS
      ↓
      /var

Cette distinction devient importante lorsque l’on commence à choisir non seulement où placer les données, mais aussi comment les stocker.

La partition racine : /

La racine / est le point de départ de l’arborescence Linux.

On y retrouve notamment le système, les programmes installés, les bibliothèques, les fichiers de configuration et de nombreux répertoires système.

Dans notre exemple, nous lui avons réservé :

/    →    80 GiB    ext4

Pourquoi 80 GiB ?

Parce que notre machine n’est pas un système minimal.

Nous installons régulièrement des logiciels, des outils de développement, des bibliothèques et différents composants nécessaires à nos expériences.

Nous avons donc préféré donner à la racine une marge confortable plutôt que de chercher à économiser chaque gigaoctet.

C’est un principe important :

Une partition système trop petite peut devenir un problème bien avant que le disque entier soit plein.

Avec une partition séparée, une saturation de /home n’implique pas automatiquement que la racine doive elle aussi être remplie.

Inversement, cela signifie que les espaces ne sont plus entièrement interchangeables.

Si /home possède 700 GiB libres mais que / est plein, ces 700 GiB ne permettent pas magiquement à la racine de continuer à écrire.

C’est l’un des compromis fondamentaux du partitionnement classique :

on gagne en isolation, mais on perd en flexibilité.

Pourquoi séparer /var ?

C’est probablement la séparation la moins évidente pour un utilisateur qui découvre Linux.

Le répertoire /var contient des données qui évoluent pendant le fonctionnement du système : journaux, caches, files d’attente, bases de données et autres données variables utilisées par les services.

Pour une machine de bureau très simple, laisser /var dans la racine est parfaitement acceptable.

Pour une machine qui fait tourner différents services, cette séparation peut en revanche devenir intéressante.

Notre propre serveur d’impression Canon nous a d’ailleurs rappelé à plusieurs reprises qu’un système Linux peut générer beaucoup plus de données variables qu’on ne l’imagine.

Dans notre exemple, nous avons donc :

/var    →    50 GiB    XFS

L’idée n’est pas que 50 GiB constitue une taille universelle.

L’idée est que /var possède son propre espace.

Si un service se met à produire énormément de fichiers temporaires, de journaux ou de données persistantes, nous pouvons limiter l’impact potentiel sur le reste du système.

Ce n’est donc pas une question de performance magique.

C’est avant tout une question de séparation des responsabilités.

Et /home ?

C’est probablement la séparation la plus facile à comprendre.

/home contient l’environnement des utilisateurs : documents, projets, fichiers personnels, configurations utilisateur et une grande partie de ce que l’on considère comme nos données.

Dans notre machine :

/home    →    785.51 GiB    XFS

Pourquoi autant ?

Parce que c’est là que se trouve l’essentiel de notre stockage de travail.

Nos projets, fichiers, archives, expérimentations et données occupent beaucoup plus d’espace que le système lui-même.

Une grande partition /home permet également de réinstaller le système sans nécessairement devoir traiter toutes les données utilisateur comme si elles appartenaient au système d’exploitation.

Attention toutefois :

Une partition séparée n’est pas une sauvegarde.

Si le SSD tombe en panne, /home tombe avec le reste du SSD.

Séparer les données du système est utile pour l’organisation et certaines opérations de maintenance.

Cela ne remplace absolument pas une véritable stratégie de sauvegarde.

Et le swap ?

Notre machine possède :

swap    →    16 GiB

Mais ici, il faut immédiatement casser une vieille habitude :

une partition swap séparée n’est pas une obligation générale pour une installation Ubuntu moderne.

Ubuntu 26.04 utilise notamment un fichier swap sur ses images Desktop, ce qui permet d’éviter d’imposer une partition swap fixe lors de l’installation.

Le système Linux peut donc utiliser un fichier comme espace d’échange, et l’outil mkswap peut lui-même travailler aussi bien avec un périphérique qu’avec un fichier.

Alors pourquoi avons-nous une partition swap ?

Parce que c’est notre choix d’organisation pour cette machine.

Ce n’est pas une règle que nous cherchons à imposer à toutes les installations Linux.

Et c’est précisément le genre de distinction qu’un bon article de partitionnement doit faire :

« voici ce que nous avons choisi » n’est pas la même chose que « voici ce que vous devez faire ».

Maintenant, parlons des systèmes de fichiers.

C’est ici que le sujet devient beaucoup plus intéressant.

Choisir une partition n’est que la moitié du problème.

Il faut ensuite choisir comment cette partition va stocker ses données.

Nous allons regarder trois noms que l’on rencontre souvent dans le monde Linux :

ext4
XFS
Btrfs

Ils peuvent tous stocker des fichiers.

Mais ils n’ont pas exactement les mêmes caractéristiques.

ext4 : le choix classique.

ext4 est probablement le système de fichiers Linux que la plupart des utilisateurs rencontreront le plus souvent.

Il apporte notamment la journalisation, les extents, l’allocation différée et différentes fonctions destinées à améliorer la robustesse et les performances.

Pour beaucoup de machines de bureau, le choix est extrêmement simple :

Need a normal Linux filesystem?
        ↓
      ext4

Ce n’est pas une règle absolue.

C’est simplement le genre de choix par défaut raisonnable que l’on peut faire sans transformer l’installation en étude d’ingénierie.

Dans notre propre machine, nous avons justement choisi ext4 pour la racine :

/    →    ext4

XFS : très intéressant, mais réfléchissez avant.

Notre /var et notre /home utilisent XFS.

XFS est un système de fichiers très mature et largement utilisé dans l’administration Linux.

Mais il possède une caractéristique que l’on doit absolument connaître avant de l’utiliser pour une nouvelle partition :

XFS peut être agrandi, mais il ne peut actuellement pas être réduit.

La documentation Red Hat décrit explicitement l’agrandissement de XFS avec xfs_growfs et précise qu’il n’est actuellement pas possible de diminuer sa taille.

Cela change beaucoup la manière dont on réfléchit au partitionnement.

Imaginez que nous créions :

/home    →    500 GiB    XFS

Puis qu’un an plus tard nous découvrions que 300 GiB auraient suffi et que nous aurions aimé rendre 200 GiB au reste du disque.

Avec XFS, on ne peut pas simplement réduire le système de fichiers pour récupérer cet espace.

Il faut donc réfléchir davantage à la taille initiale.

C’est une excellente illustration d’un principe que nous voulons vraiment retenir :

Le système de fichiers influence directement les conséquences futures de votre partitionnement.

Btrfs : une autre philosophie.

Btrfs est encore différent.

Ce n’est pas seulement « un autre formatage ».

Son modèle permet notamment d’utiliser des sous-volumes à l’intérieur d’un même système de fichiers, ainsi que des snapshots basés sur le mécanisme Copy-on-Write.

Les sous-volumes peuvent être montés comme des systèmes de fichiers indépendants tout en partageant le même espace libre du système de fichiers Btrfs. Les snapshots permettent de conserver l’état historique d’un sous-volume sans dupliquer immédiatement toutes les données.

Btrfs prend également en charge la compression transparente, notamment avec Zstandard.

Cela donne une approche assez différente :

Traditional partitions

/          → filesystem
/home      → filesystem
/var       → filesystem

versus

Btrfs filesystem
        │
        ├── subvolume
        ├── subvolume
        └── subvolume

Ce modèle peut être extrêmement intéressant pour certaines machines.

Mais là encore :

plus de possibilités signifie aussi plus de choses à comprendre.

Btrfs n’est donc pas automatiquement « meilleur » qu’ext4 ou XFS.

Il répond simplement à une autre manière de concevoir le stockage.

Alors, pourquoi notre disque est-il organisé ainsi ?

Parce qu’il correspond à notre machine et à notre façon de l’utiliser.

Notre objectif n’était pas de trouver le partitionnement parfait pour Linux.

Nous voulions une séparation claire entre plusieurs catégories de données :

/
    ↓
operating system

/var
    ↓
changing system and service data

/home
    ↓
user data and projects

swap
    ↓
swap space

Le fait que / utilise ext4 et que /var et /home utilisent XFS est également un choix réfléchi, pas une exigence de Linux.

Une autre machine pourrait très bien utiliser :

/
└── ext4

/home
└── ext4

swap
└── swapfile

et fonctionner parfaitement.

Une autre pourrait utiliser Btrfs.

Une machine serveur pourrait utiliser LVM.

Une station de travail spécialisée pourrait avoir une organisation encore différente.

Le partitionnement doit suivre le rôle de la machine.

Le vrai problème : prévoir l’avenir.

C’est probablement le point le plus important de cet article.

Lorsqu’on partitionne un disque, on ne décide pas uniquement de ce qui va se passer le jour de l’installation.

On décide aussi de ce que l’on pourra faire plus tard.

Imaginez simplement ces trois situations :

Scenario A
/      is too small
/home  has hundreds of GiB free

Scenario B
/var   is filling rapidly
/      is still almost empty

Scenario C
/home  is far larger than originally expected

Avec plusieurs partitions classiques, ces espaces sont isolés.

C’est précisément ce que nous voulions.

Mais cela signifie également qu’il faut avoir prévu les tailles correctement.

Et c’est là que beaucoup de mauvaises surprises commencent.

Ne découpez pas votre disque au hasard.

Il existe une vieille tentation lorsqu’on découvre le partitionnement manuel :

faire beaucoup de petites partitions.

/

/home

/var

/tmp

/usr

/opt

et ainsi de suite.

C’est possible.

Mais chaque séparation supplémentaire crée aussi une nouvelle limite de capacité à gérer.

Une partition presque vide ne peut pas automatiquement prêter son espace à une autre partition presque pleine.

La complexité augmente rapidement.

Partitionner plus n’est pas forcément partitionner mieux.

Un autre choix existe : LVM

Entre le monde des partitions fixes et les modèles plus sophistiqués comme Btrfs, il existe également une autre solution importante dans l’écosystème Linux :

Physical disk
      ↓
partition
      ↓
LVM
      ↓
logical volumes

LVM permet notamment de gérer plus facilement les volumes logiques et d’ajuster leur organisation dans le temps.

Ubuntu documente d’ailleurs LVM comme une option permettant de créer et gérer plus facilement les partitions après l’installation.

C’est encore une autre philosophie :

au lieu de décider une fois pour toutes exactement où chaque partition vivra, on ajoute une couche de gestion entre le disque physique et les systèmes de fichiers.

Ce n’est pas nécessaire pour une installation simple.

Mais pour certaines machines de laboratoire ou certains serveurs, cela peut être extrêmement pratique.

Ce que nous ferions avant de cliquer sur « Installer »

Avant toute installation manuelle, nous commencerions par répondre à quelques questions très simples :

1. What is this machine for?

2. Where will most of the data live?

3. What must remain isolated?

4. What may grow quickly?

5. What may need to be resized later?

6. Do I need snapshots?

7. Do I need LVM?

8. What is my backup strategy?

Et seulement après ces réponses, nous commencerions à découper le disque.

Notre SSD de 1 To résumé :

Ce partitionnement n’est donc pas une recette.

C’est une réponse à un besoin réel.

Le plus important : penser avant de partitionner

On parle souvent du partitionnement comme d’une opération technique.

En réalité, une grande partie du travail se fait avant d’ouvrir GParted, l’installateur Ubuntu ou n’importe quel autre outil.

Il faut savoir ce que l’on veut construire.

Une machine personnelle ?

Un poste de travail ?

Un serveur ?

Une station de laboratoire ?

Un système qui sera régulièrement réinstallé ?

Une machine qui devra conserver ses données utilisateur pendant plusieurs générations d’OS ?

Les réponses changent le partitionnement.

Et le choix du système de fichiers peut ensuite changer les possibilités d’évolution.

Don't start with:

"How do I install Linux?"

Start with:

"What do I want this machine
to look like in two years?"

C’est finalement cela, le vrai sujet.

Conclusion :

Installer Linux avec le partitionnement automatique est souvent parfaitement suffisant.

Mais lorsqu’on possède une machine que l’on souhaite conserver, faire évoluer ou utiliser comme véritable environnement de travail, il peut être intéressant de prendre quelques minutes avant l’installation pour réfléchir à l’organisation du stockage.

Notre propre SSD de 1 To montre une possibilité :

1 TB SSD
      ↓
/
├── system
│
├── /var
│   └── changing data
│
├── /home
│   └── user data
│
└── swap
    └── swap space

Mais une autre installation pourrait être très différente.

Il n’existe pas un partitionnement Linux universel qui conviendrait à toutes les machines.

Il existe seulement des choix plus ou moins adaptés à un usage donné.

Et c’est précisément pour cette raison qu’il vaut mieux réfléchir avant de partitionner qu’après.

Le disque est grand.
Mais l’espace n’est pas une stratégie.

StalkerLabs — Break it. Understand it. Document it.