Utilisation du disque Linux et dépannage des systèmes de fichiers avec df, du, lsblk, mount et fstab : guide pratique

Introduction

Linux disk usage et Linux filesystem troubleshooting ne sont pas que des sujets de fond : ils déterminent la fiabilité des environnements de développement, CI/CD et production. Démarrer un conteneur ou une VM est simple ; opérer durablement l'espace disque, les montages et les permissions l'est moins. Ce guide pratique relie les commandes df, du, lsblk, mount et fstab à des scénarios concrets (no space left on device, partitions pleines, inodes épuisés) et à des contrôles locaux reproductibles. L'objectif est de comprendre les pièces mobiles, les tester, et éviter les surprises lors du passage à un environnement proche de la production.

Vue d'ensemble du workflow

Approche recommandée :

Identifier la ressource concernée (périphérique bloc, point de montage, partition, quotas, inodes).
Indiquer la configuration qui l'affecte (entrée fstab, options de montage, permissions, limites).
Choisir la commande de preuve (df/du pour l'usage, lsblk/findmnt pour la topologie, mount pour l'activation).
Définir le signal d'échec attendu (erreur de montage, no space left on device, permission denied, incohérence df/du).

Avant de modifier l'environnement, rendez explicites les hypothèses : chemins locaux, versions d'image, variables d'environnement, limites de ressources et Linux permissions. Une bonne vérification locale doit être rejouable par un autre développeur à partir d'un clone propre, avec les commandes proches des fichiers de configuration.

Inventaire : périphériques et montages

Commencez par cartographier les disques et systèmes de fichiers.

Voir les périphériques blocs et leurs FS/UUID :

lsblk -f

Lister les montages actifs et la hiérarchie :

findmnt -a
# ou
mount | column -t

Vérifier le point de montage d'un chemin :

mountpoint -q /data && echo "/data est un point de montage" || echo "/data n'est pas un point de montage"

Inspecter /etc/fstab (source des montages persistants) :

cat /etc/fstab

Exemple d'entrée fstab correcte :

UUID=1234-ABCD  /data  ext4  defaults, noatime  0  2

Bonnes pratiques fstab :

Utiliser UUID= plutôt que /dev/sdX pour éviter les surprises d'ordre des disques.
Créer le point de montage avant (sudo mkdir -p /data).
Tester prudemment :

sudo mount -a

Si une option ou un type est invalide, la commande échouera avec un message clair.

Mesurer l'usage : blocs vs inodes

Différencier saturation de blocs et épuisement d'inodes est essentiel.

Occupation par blocs et type de FS :

df -hT

Inodes restants (nombre de fichiers/entrées) :

df -i

Repérer les répertoires volumineux sans sortir du FS courant :

sudo du -xh --max-depth=1 /var | sort -h | tail -n 10

Options clés :

-x pour rester sur le même système de fichiers.
--max-depth=1 pour un aperçu par dossier.

Rappels :

"no space left on device" peut venir d'un manque de blocs OU d'inodes. Si df -h montre de l'espace mais df -i est à 0 % disponible, vous avez épuisé les inodes (trop de petits fichiers).
Les écarts df/du peuvent signaler des fichiers supprimés mais toujours ouverts par un processus.

Pannes courantes et signaux d'échec

Point de montage manquant ou erroné

Symptôme : les écritures vont sur / (rootfs) au lieu de /data.
Vérification : mountpoint /data, findmnt /data.
Correction : réparer /etc/fstab, créer le dossier, puis sudo mount -a.

Fichiers supprimés mais encore ouverts

Symptôme : df -h reste plein malgré suppression de gros fichiers.
Diagnostic :

sudo lsof +L1 | grep deleted

Correction : redémarrer le service fautif ou le processus qui retient le descripteur.

Épuisement d'inodes

Symptôme : erreurs no space left on device alors que df -h laisse penser le contraire.
Diagnostic : df -i puis identifier l'arborescence à très nombreux petits fichiers (cache, files temporaires).
Correction : purge ciblée, revoir la stratégie d'archivage/rotation.

Erreurs fstab

Symptôme : au boot ou mount -a, messages « wrong fs type », « bad option », « failed to mount ».
Causes fréquentes : mauvais fstype, UUID incorrect, options invalides, oubli du point de montage, manque de nofail pour éviter un blocage si le disque est absent.

Permissions

Symptôme : permission denied malgré espace suffisant.
Vérification : ls -ld /data, id, umask. Corriger avec chown/chmod selon le besoin applicatif.

Nettoyage sûr et préventif

Avant de supprimer, confirmez la cause (blocs, inodes, montage). Privilégiez des actions réversibles et ciblées.

Journaux systemd :

sudo journalctl --vacuum-time=7d
# ou limiter la taille totale
sudo journalctl --vacuum-size=1G

Caches des paquets (exemples) :

sudo apt-get clean
# ou
sudo dnf clean all

Répertoires les plus gros :

sudo du -xh --max-depth=1 / | sort -h | tail -n 20

Supprimer ensuite de manière ciblée, idéalement hors des zones système critiques.

Fichiers supprimés mais ouverts : identifiez avec lsof, puis redémarrez le service concerné.
Rotation des logs :

sudo logrotate -f /etc/logrotate.conf

Bonnes pratiques :

Éviter rm -rf précipités sur / ou /var sans audit préalable.
Utiliser du -x pour ne pas déborder sur d'autres montages (ex. /home, /data).
Documenter chaque commande de nettoyage appliquée et son impact attendu.

Plan pilote local (reproductible)

Mettez en place un test local contrôlé pour observer les signaux d'échec et de réussite.

Créer un disque de test en loopback et le monter

sudo dd if=/dev/zero of=/tmp/pilot.img bs=1M count=512
sudo mkfs.ext4 /tmp/pilot.img
sudo mkdir -p /mnt/pilot
sudo mount -o loop /tmp/pilot.img /mnt/pilot

Vérifier :

df -hT /mnt/pilot
findmnt /mnt/pilot

Remplir progressivement et observer

# écrire ~100 Mo de données factices
head -c 100M </dev/urandom > /mnt/pilot/blob1
sudo du -xh --max-depth=1 /mnt/pilot

Répéter jusqu'à provoquer l'erreur attendue :

head -c 600M </dev/urandom > /mnt/pilot/blob2 || echo "no space left on device"

Contrôler :

df -h /mnt/pilot

Tester l'épuisement d'inodes (petits fichiers)

for i in $(seq 1 50000); do echo x > /mnt/pilot/f_$i || break; done

Observer :

df -i /mnt/pilot

Simuler une entrée fstab et valider

UUID=$(blkid -s UUID -o value /tmp/pilot.img)
echo "UUID=$UUID /mnt/pilot ext4 defaults, noatime, nofail 0 2" | sudo tee -a /etc/fstab
sudo mount -a
findmnt /mnt/pilot

Corriger toute erreur, puis documenter l'entrée retenue.

Remise en état

sudo umount /mnt/pilot
sudo sed -i.bak '/\/mnt\/pilot/d' /etc/fstab
sudo rm -f /tmp/pilot.img

Critères de réussite du pilote :

lsblk/findmnt reflètent correctement le montage.
df -h et df -i se comportent comme attendu (blocs vs inodes).
du localise précisément ce qui consomme.
Les erreurs sont reproductibles et observables (no space left on device), puis résolues par des corrections connues (libérer, corriger fstab, remonter).

Conclusion

Linux disk usage et Linux filesystem troubleshooting sont plus fiables lorsqu'ils sont traités comme un ensemble de tests vérifiables. Tenez des exemples petits, exécutez df, du, lsblk, mount et validez fstab localement avant d'ajouter d'autres services ou de l'automatisation. Un bon workflow rend la panne visible : messages d'erreur explicites, journaux accessibles, données persistantes correctement montées. Pour la suite, choisissez un service, décrivez les commandes exactes pour le construire, l'exécuter, l'inspecter, l'arrêter et le recréer, puis comparez avec la Linux filesystem hierarchy, les Linux permissions et la Linux storage troubleshooting afin d'inscrire la solution dans un modèle d'exploitation cohérent. Enfin, surveillez systématiquement les signaux clés (df -h, df -i, cohérence findmnt/fstab) pour prévenir les "no space left on device" et garantir des déploiements sans surprises.