Contrôle du système de fichiers Debian 13 prend une éternité : ce qui est normal, signaux d’alerte et solutions (cas n°31)

Ce qui est normal vs ce qui est un signal d’alerte

Première chose : comprendre quel type de « vérification » vous regardez

On dit « fsck » comme si c’était une seule chose. Ce n’est pas le cas. Sur Debian 13 vous pouvez voir :

• Rejeu du journal (plutôt rapide) : ext4 rejoue son journal après un arrêt non propre. Ce n’est pas une analyse complète ; c’est essentiellement l’application des dernières écritures transactionnelles. Souvent quelques secondes à quelques minutes.
• Vérification complète du système de fichiers (lente) : analyse les métadonnées et parfois les arbres de répertoires et les inœuds. C’est celle qui peut prendre des heures sur des volumes de plusieurs téraoctets.
• Reconstruction du périphérique/RAID (pas fsck) : mdadm resync ou reconstruction de contrôleur qui rend chaque lecture lente, si bien que fsck semble « bloqué ».
• Récupération d’erreur au niveau du stockage (la plus inquiétante) : le disque/SSD réessaie des lectures, le noyau journalise des erreurs E/S, et fsck attend le périphérique bloc.

Quel est le temps « normal » ?

Le normal dépend de la quantité de métadonnées, pas seulement de la taille brute du disque, et de votre profil d’E/S (HDD vs SATA SSD vs NVMe, local vs réseau, et si votre contrôleur est de mauvaise humeur). Quelques heuristiques pratiques :

• Rejeu du journal : généralement moins d’une minute sur SSD/NVMe, quelques minutes sur HDD, plus long si votre stockage est saturé ou dégradé.
• fsck ext4 complet : peut prendre 10–30 minutes par téraoctet sur disques rotatifs dans des conditions décentes. Sur SSD/NVMe, ça peut être beaucoup plus rapide, mais ne misez pas votre sommeil d’astreinte là-dessus.
• Grand nombre d’inodes : des millions de petits fichiers sont la taxe classique de fsck. Un volume de 500 Go avec 200 millions d’inodes peut prendre plus de temps qu’un volume de 4 To contenant surtout de gros fichiers.

À quoi ressemble une « éternité » : signaux d’alerte à traiter comme incidents

Ce sont les moments où il faut arrêter d’attendre et commencer à diagnostiquer :

• Aucune activité disque pendant des minutes alors que fsck prétend s’exécuter, et le journal système affiche des erreurs ou des délais d’E/S répétés.
• Progression bloquée à une passe spécifique (pour ext4 : Pass 1, 2, 3, 4, 5) pendant longtemps sur un petit système de fichiers. Un grand système peut légitimement ramper, mais « bloqué » sur un disque root de 50 Go est suspect.
• Messages du noyau concernant des réinitialisations, lien down/up, ou erreurs NCQ. Ce n’est pas la complexité du système de fichiers ; c’est le périphérique qui demande une retraite.
• fsck affiche « UNEXPECTED INCONSISTENCY » ou demande des corrections pendant le démarrage. Vous êtes en réparation interactive pendant le chemin de démarrage. C’est un piège pour les systèmes non surveillés.
• Les redémarrages répètent la vérification à chaque boot, même après qu’elle « se termine ». Cela peut signifier que le système de fichiers ne se remonte jamais proprement, ou que le périphérique bloc sous-jacent ment.

Un modèle mental rapide : si fsck est lent mais que le disque travaille régulièrement, vous avez probablement un problème d’échelle mais pas nécessairement dangereux. Si fsck est lent et que le disque ne fait aucun travail, ou que le noyau hurle, vous avez probablement un problème dangereux (matériel ou corruption).

Faits et contexte intéressants (pourquoi fsck se comporte ainsi)

• Fait 1 : Le classique ext2 nécessitait des vérifications complètes régulières car il n’avait pas de journal ; le journal d’ext3/ext4 a réduit le besoin de scans complets fréquents.
• Fait 2 : ext4 utilise des sommes de contrôle des métadonnées et des améliorations du journal qui rendent certaines corruptions plus faciles à détecter, mais la détection ne rend pas automatiquement les réparations rapides.
• Fait 3 : Un démontage « propre » est un bit dans le superbloc. Si le système perd l’alimentation, ce bit ne se met pas à jour, et le prochain montage peut déclencher une vérification — même si les données utilisateur sont intactes.
• Fait 4 : tune2fs peut programmer des vérifications par nombre de montages ou intervalle de temps ; de nombreux systèmes passent des années sans vérification complète car les valeurs par défaut sont conservatrices pour les serveurs.
• Fait 5 : Le répertoire lost+found existe parce que fsck peut « récupérer » des fichiers orphelins en les reconnectant. C’est le tiroir à bazar du système de fichiers.
• Fait 6 : L’« initialisation paresseuse de la table d’inodes » d’ext4 accélère la création de nouveaux systèmes de fichiers, mais signifie aussi que l’initialisation en arrière-plan peut concurrencer les E/S au début de la vie du système de fichiers.
• Fait 7 : Les SSD peuvent devenir lents sans « échouer » de manière spectaculaire ; le firmware peut consacrer du temps au garbage collection interne ou à la correction d’erreurs, ce qui apparaît sous forme de pics de latence et de ralentissements de fsck.
• Fait 8 : Sur de grands ensembles RAID, une reconstruction peut diviser par deux la bande passante effective en lecture. fsck devient alors le messager blâmé.

Une citation d’ingénierie qui a survécu à suffisamment d’analyses post-mortem pour mériter une place à table : « L’espoir n’est pas une stratégie. » Cette phrase est largement attribuée dans la culture ops ; considérez-la comme une idée paraphrasée issue du savoir-faire en fiabilité, pas comme un texte sacré.

Blague #1 : Regarder la progression de fsck, c’est comme regarder de la peinture sécher, sauf que la peinture vous demande parfois de choisir entre deux mauvaises options.

Procédure de diagnostic rapide (trouver le goulot d’étranglement)

Votre objectif : décider dans quel cas vous vous trouvez en 5–10 minutes.

Première étape : est-ce qu’on exécute vraiment une vérification de système de fichiers, et sur quel périphérique ?

• Vérifiez les messages de la console de démarrage et l’état des unités systemd si vous y avez accès.
• Identifiez le périphérique bloc qui supporte le système de fichiers (/dev/nvme0n1p2, /dev/md0, LV LVM, etc.).

Deuxième étape : la pile de stockage est-elle saine actuellement ?

• Cherchez des erreurs d’E/S du noyau, des réinitialisations de lien, des délais d’attente du contrôleur.
• Vérifiez la santé SMART et les compteurs d’erreurs actuels.
• Si un RAID est impliqué, vérifiez l’état de resync/rebuild.

Troisième étape : fsck fait-il des progrès ou est-il bloqué sur des E/S ?

• Mesurez l’utilisation et la latence du périphérique (même des chiffres approximatifs aident).
• Surveillez les lectures régulières ; une sortie « coincée » peut quand même indiquer un scan actif.
• Décidez s’il faut le laisser finir, redémarrer en mode rescue, ou arrêter et imager le disque.

Arbre de décision à utiliser réellement

• Si les logs du noyau montrent des erreurs/délais d’E/S : traitez comme une défaillance possible du disque. Priorisez la sécurité des données : imagez/sauvegardez, remplacez le matériel, puis réparez le système de fichiers.
• Si une reconstruction RAID/resync est active : attendez-vous à de la lenteur ; envisagez de mettre la resync en pause (avec précaution) ou de programmer fsck après stabilisation.
• Si pas d’erreurs et que les E/S sont actives : c’est probablement un long scan légitime. Laissez-le finir, mais planifiez des mesures d’atténuation futures (tuning, découpage des systèmes de fichiers, stockage plus rapide).
• Si des questions interactives apparaissent pendant le démarrage : stoppez cela. Utilisez le mode rescue et exécutez une réparation contrôlée avec journalisation.

Tâches pratiques : commandes, sorties et décisions (12+)

Ces étapes sont écrites pour Debian 13 avec systemd. Adaptez les noms de périphériques à votre réalité. Chaque tâche inclut : commande, ce que la sortie signifie, et quelle décision prendre.

Task 1: Identify what systemd is waiting on (boot-time fsck)

cr0x@server:~$ systemctl list-jobs
JOB UNIT                       TYPE  STATE  
123 systemd-fsck@dev-disk-by\x2duuid-... service running
124 dev-mapper-vg0-root.device  start waiting

2 jobs listed.

Sens : Une unité systemd fsck est activement en cours pour un périphérique identifié par UUID.

Décision : Résoudre ensuite à quel périphérique bloc cet UUID correspond, et vérifier les erreurs d’E/S avant de supposer que c’est « juste lent ».

Task 2: Map filesystem UUID to a device

cr0x@server:~$ ls -l /dev/disk/by-uuid | head
total 0
lrwxrwxrwx 1 root root 10 Dec 30 02:11 1a2b3c4d-... -> ../../sda1
lrwxrwxrwx 1 root root 15 Dec 30 02:11 7f8e9d0c-... -> ../../dm-0
lrwxrwxrwx 1 root root 10 Dec 30 02:11 9abc0123-... -> ../../sda2

Sens : L’UUID se résout en une partition (sda1) ou un nœud device-mapper (dm-0 pour LVM/crypt).

Décision : Si c’est dm-*, identifiez aussi les PV sous-jacents. Un fsck lent sur dm-0 peut être dû à un disque défaillant sous LVM.

Task 3: Check recent kernel logs for IO pain

cr0x@server:~$ dmesg -T | tail -n 25
[Mon Dec 30 02:12:11 2025] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Mon Dec 30 02:12:11 2025] ata1.00: failed command: READ FPDMA QUEUED
[Mon Dec 30 02:12:11 2025] blk_update_request: I/O error, dev sda, sector 12345678 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[Mon Dec 30 02:12:12 2025] EXT4-fs (sda2): I/O error while writing superblock

Sens : Ce n’est pas un « fsck lent ». Ce sont des erreurs de lecture et des blocages de lien. ext4 n’a pas non plus pu écrire le superbloc proprement.

Décision : Arrêtez de considérer cela comme un problème purement lié au système de fichiers. Préparez le remplacement du disque ; priorisez une copie au niveau bloc ou une sauvegarde avant d’effectuer des écritures de réparation répétées.

Task 4: Check which filesystems are configured for automatic checks

cr0x@server:~$ cat /etc/fstab
UUID=7f8e9d0c-... /     ext4  defaults,errors=remount-ro  0  1
UUID=1a2b3c4d-... /boot ext4  defaults                  0  2
UUID=9abc0123-... /data ext4  defaults                  0  2

Sens : La dernière colonne est l’ordre de passage pour fsck. Root est 1 (en premier), les autres sont 2 (après root), 0 désactive fsck.

Décision : Si vous avez un volume de données énorme en pass 2 qui cause des délais de démarrage longs, envisagez de le mettre à 0 et d’exécuter fsck dans une fenêtre de maintenance. Ne le faites pas pour cacher une corruption ; faites-le pour contrôler l’impact.

Task 5: See ext4 check schedule and last check time

cr0x@server:~$ sudo tune2fs -l /dev/sda2 | egrep -i 'Filesystem state|Mount count|Maximum mount count|Last checked|Check interval'
Filesystem state:         not clean
Mount count:              41
Maximum mount count:      42
Last checked:             Sun Dec  1 03:10:22 2025
Check interval:           15552000 (6 months)

Sens : Vous avez atteint le seuil de nombre de montages, ou le système de fichiers est marqué « not clean », donc une vérification complète est déclenchée.

Décision : Si c’est un déclencheur de maintenance planifiée, laissez-le s’exécuter. Si c’est inattendu, demandez pourquoi le système de fichiers devient « not clean » (coupure d’alimentation, kernel panic, délais d’attente du stockage).

Task 6: Get real-time insight into what fsck is doing (process view)

cr0x@server:~$ ps -eo pid,etime,stat,cmd | grep -E 'fsck|e2fsck' | grep -v grep
  622 01:17:43 D    /sbin/e2fsck -p -C 0 /dev/sda2

Sens : L’état D indique souvent un sommeil non interruptible, généralement en attente d’E/S. C’est un indice fort quand c’est accompagné d’erreurs disque ou d’une latence élevée.

Décision : Si c’est bloqué en D et que vous avez des erreurs d’E/S, arrêtez et diagnostiquez le disque. Si c’est en R ou S avec des E/S régulières, cela peut être acceptable.

Task 7: Measure device latency and utilization (quick and dirty)

cr0x@server:~$ iostat -x 1 5
Linux 6.12.0 (server)  12/30/2025  _x86_64_ (8 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          1.20  0.00    2.40   72.00    0.00   24.40

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await aqu-sz  %util
sda             90.0  14400.0     0.0   0.00  850.00   160.00      2.0     64.0  120.00  40.00  99.00

Sens : r_await à 850ms et %util à ~99% signifie que le disque est saturé et lent. L’iowait est énorme. Voilà pourquoi fsck ressemble à de la mélasse.

Décision : Si c’est un HDD unique sur un grand système de fichiers, cela peut encore être « normal » mais pénible. Si c’est un SSD/NVMe, c’est un signal d’alerte : problèmes de firmware, média défaillant, ou RAID dégradé.

Task 8: Check SMART health and error counters

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'SMART overall|Reallocated|Pending|Offline|Error|Power_On_Hours'
SMART overall-health self-assessment test result: FAILED!
Reallocated_Sector_Ct   0x0033   001   001   005    Pre-fail  Always       -       8123
Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       97
Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       97
ATA Error Count: 203

Sens : Des secteurs en attente/offline-uncorrectable signifient que le disque ne peut pas lire certaines données de manière fiable. fsck va marteler ces zones et se bloquer.

Décision : Remplacez le disque. Avant d’exécuter des options de réparation agressives, imagez ou sauvegardez ce que vous pouvez. Chaque réparation ajoute des écritures sur un disque défaillant.

Task 9: Check mdadm RAID state (if applicable)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      976630336 blocks super 1.2 [2/1] [U_]
      [========>............]  recovery = 41.2% (402123456/976630336) finish=210.3min speed=45512K/sec

Sens : Le volume est dégradé ([U_]) et en cours de récupération. Les lectures peuvent être plus lentes ; la contention E/S peut faire ramper fsck.

Décision : Si les données sont critiques et que les performances s’effondrent, il peut être préférable de terminer la récupération d’abord, puis de lancer la vérification du système de fichiers, plutôt que de mélanger deux opérations lourdes.

Task 10: If using LVM, confirm which PV is slow

cr0x@server:~$ sudo lvs -a -o +devices
  LV   VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  root vg0 -wi-ao---- 120.00g                                                     /dev/sda2(0)
  data vg0 -wi-ao----   3.50t                                                     /dev/sdb1(0)

Sens : Vous pouvez mapper un système de fichiers lent à un disque physique. Si / est sur sda2, vous savez où concentrer les vérifications SMART et le câblage.

Décision : Ne devinez pas. Si le volume s’étend sur plusieurs PV, trouvez le maillon le plus faible, plutôt que d’exécuter fsck plusieurs fois en espérant un résultat.

Task 11: Run a controlled fsck from rescue mode (read-only first)

cr0x@server:~$ sudo e2fsck -f -n -v /dev/sda2
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Inode 774533 has illegal block(s).  Clear? no
Pass 2: Checking directory structure
Entry 'tmp123' in /var/tmp (12345) has deleted/unused inode 778899.  Clear? no
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 164233/7864320 files, 19200322/31457280 blocks

Sens : -n signifie « pas de changements », donc c’est sûr pour l’évaluation. Il indique quand même ce qu’il corrigerait et si des modifications seraient nécessaires.

Décision : S’il indique « WAS MODIFIED » même avec -n, cela signifie que des changements sont requis. Planifiez une fenêtre d’indisponibilité et exécutez sans -n (ou utilisez -p pour preen) seulement après avoir confirmé que le disque est assez sain pour supporter des écritures.

Task 12: Run repair with logging (and accept that you own the outcome)

cr0x@server:~$ sudo e2fsck -f -y -v /dev/sda2 | tee /root/e2fsck-root.log
Pass 1: Checking inodes, blocks, and sizes
Inode 774533 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
...
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 164233/7864320 files, 19200320/31457280 blocks

Sens : -y répond « oui » aux invites. C’est une réparation à la hache. Utile pour une récupération non supervisée, dangereux si le problème sous-jacent est matériel.

Décision : Utilisez -y lorsque vous avez décidé que restaurer la montabilité est plus important que préserver chaque nom de fichier. Pour les systèmes critiques, envisagez une stratégie sauvegarde/restauration plutôt qu’une réparation agressive.

Task 13: Check ext4 features that may affect check behavior

cr0x@server:~$ sudo dumpe2fs -h /dev/sda2 | egrep -i 'Filesystem features|Checksum|metadata_csum|64bit'
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit metadata_csum

Sens : Les fonctionnalités modernes d’ext4 comme metadata_csum et 64bit sont normales sur de grands systèmes de fichiers. Elles peuvent modifier la manière dont les vérifications sont effectuées et à quoi ressemblent les erreurs.

Décision : Si vous migrez des disques entre des chaînes d’outils plus anciennes, assurez-vous que votre environnement de secours dispose d’un e2fsck récent. Outils anciens + fonctionnalités modernes = mauvaise journée.

Task 14: Confirm mounts and avoid running fsck on a mounted filesystem

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE / /data
/dev/sda2 / ext4
/dev/sdb1 /data ext4

Sens : Affiche quels périphériques sont montés où.

Décision : Ne lancez pas un fsck en écriture sur un système de fichiers monté. Si vous devez vérifier un ext4 monté, utilisez fsck -n seulement pour l’inspection et planifiez une indisponibilité pour de vraies réparations.

Task 15: Force a check next reboot (controlled, not accidental)

cr0x@server:~$ sudo touch /forcefsck
cr0x@server:~$ ls -l /forcefsck
-rw-r--r-- 1 root root 0 Dec 30 02:45 /forcefsck

Sens : De nombreuses configurations Debian respectent /forcefsck au démarrage pour déclencher des vérifications.

Décision : Utilisez-le lorsque vous voulez une vérification planifiée, pas lorsque vous pariez sur une surprise de deux heures de délai de démarrage pendant une fenêtre de déploiement.

Task 16: Find why the previous shutdown was unclean

cr0x@server:~$ journalctl -b -1 -p warning..alert | tail -n 30
Dec 30 01:58:09 server kernel: EXT4-fs warning (device sda2): ext4_end_bio:345: I/O error 10 writing to inode 2625315 starting block 1234567)
Dec 30 01:58:12 server systemd[1]: Failed to start Flush Journal to Persistent Storage.
Dec 30 01:58:16 server kernel: Kernel panic - not syncing: Fatal exception

Sens : Le démarrage précédent s’est mal terminé. fsck n’est pas la cause ; c’est la conséquence.

Décision : Corrigez le déclencheur (erreurs disque, panic kernel, problèmes d’alimentation) ou vous reviendrez ici, appréciant la même « vérification de système de fichiers qui prend une éternité ».

Trois mini-récits du monde de l’entreprise (ce qui arrive réellement)

1) Incident causé par une mauvaise hypothèse : « C’est juste un grand disque »

Une entreprise de taille moyenne exploitait une flotte Debian hébergeant des artefacts de build internes. Un matin, un runner de build critique n’a pas démarré. La console affichait une vérification ext4. L’astreinte a hausser les épaules : grand disque, beaucoup de fichiers, ça finira bien.

Deux heures plus tard, toujours en cours. Les messages de progression avançaient lentement, mais pas au rythme attendu d’un hôte NVMe. La première erreur de l’équipe fut de supposer que « lent » équivalait à « normal », et de ne pas regarder les logs du noyau. Ils traitaient fsck comme une tâche de maintenance, pas comme un symptôme.

Finalement, quelqu’un a regardé dmesg et a trouvé des réinitialisations de lien sur le chemin SATA alimentant un SSD SATA bon marché utilisé comme couche de cache « temporaire » devenue permanente. Les lectures étaient en retry. Le disque n’était pas mort ; il mourait poliment en traînant tout le monde.

La réparation s’est achevée, mais le système de fichiers a nécessité une autre vérification au prochain démarrage parce que le disque a lancé d’autres erreurs lors des dernières écritures du superbloc. Ce n’est qu’alors qu’ils ont arrêté et remplacé le périphérique. La leçon était douloureusement ennuyeuse : les erreurs de stockage se déguisent en « longues vérifications » avant de devenir des pannes évidentes.

Par la suite, ils ont ajouté un runbook : si fsck dépasse un seuil, vérifier SMART et dmesg dans les dix minutes. Pas parce qu’ils aiment les processus, mais parce qu’ils aiment dormir.

2) Optimisation qui a mal tourné : « Accélérons la reconstruction RAID »

Une autre organisation opérait une paire de grands RAID1 sur des serveurs commodity. Un disque est tombé, la reconstruction RAID a démarré, et quelqu’un a décidé « d’optimiser » en augmentant la vitesse de reconstruction pour raccourcir la fenêtre dégradée. Sur le papier, c’était logique : reconstruction plus rapide, moins de risque.

En réalité, la machine hébergeait aussi une base de données critique et une pile de jobs de traitement de logs. L’augmentation de l’agressivité de la reconstruction a affamé les lectures sensibles à la latence. La base de données a commencé à timeouter, les profondeurs de queue du noyau ont augmenté, et est venu le redémarrage — parce que quelqu’un a estimé que la base de données « gelait ». Ce n’était pas vrai. Elle étouffait.

Au redémarrage, la vérification du système de fichiers a démarré. Maintenant fsck se retrouvait en compétition avec la récupération RAID encore active. L’« optimisation » a transformé une journée à un problème en une journée à deux problèmes : RAID dégradé plus fsck douloureusement lent, plus le temps de récupération des applications.

La correction n’était pas héroïque. Ils ont remis la vitesse de reconstruction à une valeur conservatrice pendant les heures de travail, planifié les reconstructions et vérifications lourdes hors-pointe, et introduit une surveillance de la latence, pas seulement du débit. Ils ont aussi arrêté de redémarrer des machines parce que les applications semblaient lentes. Si vous redémarrez une machine en détresse, vous redémarrez surtout vos propres hypothèses.

3) Pratique ennuyeuse mais correcte qui a sauvé la situation : « Fenêtres de maintenance et récupération répétée »

Une troisième équipe exploitait des serveurs Debian pour un environnement soumis à conformité. Ils avaient la culture d’ingénierie la moins excitante qu’on puisse imaginer, et c’était splendide. Ils planifiaient des fenêtres de maintenance trimestrielles du stockage, incluant redémarrages contrôlés, vérification des attributs SMART, et un fsck planifié sur un sous-ensemble tournant de machines.

Quand un hôte a finalement subi un arrêt non propre dû à un problème de distribution électrique, l’astreinte a vu un long fsck et n’a pas paniqué. Ils avaient déjà des baselines : combien de temps une vérification complète prend sur ce volume et ce matériel spécifiques, et à quoi ressemblent les passes normales. Ils disposaient aussi d’une image de secours connue bonne avec des versions e2fsck compatibles.

Lors du diagnostic ils n’ont trouvé aucune erreur d’E/S, juste un système de fichiers marqué non propre. Ils l’ont laissé finir, il s’est terminé dans la fenêtre attendue, et les services sont revenus. Pas de drame, pas d’improvisation héroïque.

Le lendemain ils ont audité l’événement d’alimentation, confirmé qu’il ne se reproduisait pas, et ont continué. Leur « sauce secrète » n’était pas l’intelligence. C’était la répétition et des baselines ennuyeuses. Le genre de trucs que personne ne veut financer jusqu’à ce que la facture de l’incident arrive.

Blague #2 : Les systèmes de fichiers ressemblent aux organigrammes d’entreprise — tout semble cohérent jusqu’à ce que vous essayiez de concilier qui relève de qui.

Erreurs fréquentes : symptôme → cause racine → correction

1) « fsck est bloqué à 0–5% pour toujours »

Symptôme : Une passe initiale prend une éternité, la console montre peu de mouvement.

Cause racine : Le périphérique renvoie des lectures avec une très grande latence à cause des retries, ou vous êtes sur un RAID dégradé/en resync.

Correction : Vérifiez dmesg pour des erreurs d’E/S, lancez iostat -x pour await/%util, et inspectez les compteurs SMART. Si le RAID est en reconstruction, décidez s’il faut finir la reconstruction d’abord.

2) « fsck s’exécute à chaque démarrage »

Symptôme : Le système vérifie toujours root au démarrage même après un arrêt propre.

Cause racine : Le système de fichiers n’est jamais marqué propre : erreurs de stockage, vérifications forcées par politique de nombre de montages, ou arrêts qui n’atteignent pas le démontage propre.

Correction : Confirmez l’état/compte de montages avec tune2fs -l, vérifiez les logs pour le plantage précédent, corrigez le problème sous-jacent de reboot/alimentation, et assurez-vous que l’arrêt se termine correctement.

3) « Il demande une intervention manuelle pendant le démarrage »

Symptôme : Le démarrage bascule sur une invite demandant de corriger les erreurs.

Cause racine : Erreurs non pré-enables ou mismatch de politique (le système attend -p mais des erreurs nécessitent des décisions manuelles).

Correction : Démarrez en rescue/emergency, exécutez d’abord e2fsck -f -n pour évaluer, puis réparez avec journalisation. Envisagez d’ajuster la manière dont le système gère les vérifications pour éviter des boots interactifs en production.

4) « fsck est lent sur NVMe, qui devrait être rapide »

Symptôme : Des minutes ressemblent à des heures sur du stockage moderne.

Cause racine : Thermal throttling NVMe, correction d’erreur au niveau firmware, problèmes de lien PCIe, ou contention de stockage en virtualisation.

Correction : Vérifiez dmesg pour des réinitialisations NVMe, utilisez iostat pour voir les awaits, et inspectez la santé SMART NVMe. Si virtualisé, vérifiez la santé du stockage hôte et les voisins bruyants.

5) « Nous avons désactivé fsck dans fstab et maintenant la corruption a empiré »

Symptôme : Après une série de crashs, le système de fichiers se monte mais se comporte étrangement, puis devient non démontable.

Cause racine : Désactiver les vérifications pour accélérer les démarrages a caché l’aggravation des problèmes de métadonnées.

Correction : Réactivez les vérifications pour root, planifiez des vérifications pour les gros volumes de données, et construisez un workflow de maintenance au lieu d’espérer que le journal suffise.

6) « Nous avons lancé fsck sur un système de fichiers monté et ça a merdé »

Symptôme : Des fichiers disparaissent, des répertoires se comportent mal, des erreurs augmentent ensuite.

Cause racine : Exécuter une réparation pendant que le système de fichiers est monté et en cours de modifications.

Correction : Arrêtez. Remontez en lecture seule si possible, puis réparez hors-ligne depuis le rescue ou après un reboot de maintenance. Si les données sont critiques, faites un snapshot/sauvegarde d’abord.

Listes de contrôle / plan étape par étape

Checklist A: Quand fsck s’exécute au démarrage et que vous êtes d’astreinte

1. Confirmez ce qui tourne : identifiez l’unité fsck et le périphérique (Tâches 1–2).
2. Regardez les erreurs du noyau liées au stockage : dmesg et le journal du démarrage précédent (Tâches 3 et 16).
3. Mesurez la santé E/S : iostat -x pour latence/utilisation (Tâche 7).
4. Vérifiez SMART / NVMe : confirmez que vous n’êtes pas en train de grincer sur un périphérique défaillant (Tâche 8).
5. Vérifiez les couches RAID/LVM : assurez-vous que vous ne compétez pas avec une reconstruction ou un chemin dégradé (Tâches 9–10).
6. Décidez :
   • Si erreurs du périphérique : arrêtez les réparations répétées, planifiez le remplacement du disque et la récupération des données.
   • Si pas d’erreurs mais grand volume : laissez-le tourner ; communiquez une plage ETA, pas une promesse.
   • Si invites interactives : redémarrez en rescue et effectuez une réparation contrôlée avec journalisation.

Checklist B: Workflow de réparation contrôlée (le plan « je veux récupérer ma vie »)

1. Démarrez en mode rescue/emergency ou depuis une image d’installateur/live.
2. Assurez-vous que le système de fichiers est démonté : vérifiez avec findmnt (Tâche 14).
3. Exécutez une évaluation en lecture seule : e2fsck -f -n -v (Tâche 11).
4. Si le disque est assez sain, lancez la réparation avec journalisation : e2fsck -f -y -v | tee (Tâche 12).
5. Relancez fsck jusqu’à ce qu’il indique un état clean. Un seul passage n’est pas toujours suffisant après des réparations lourdes.
6. Montez et vérifiez par des contrôles de sanity : confirmez les répertoires clés, services, et checksums applicatifs si vous en avez.
7. Après le démarrage, collectez des preuves : SMART, logs noyau, et le fichier de log fsck pour le dossier d’incident.

Checklist C: Prévenir la prochaine marathon de fsck à 3h du matin

1. Établissez des temps de vérification de référence par classe d’hôte (HDD vs SSD vs NVMe, RAID vs non-RAID).
2. Assurez la surveillance et les alertes sur la latence disque et la dégradation SMART, pas seulement « disque plein ».
3. Revoyez les valeurs de pass dans /etc/fstab. Ne laissez pas des volumes de plusieurs téraoctets bloquer les démarrages à moins que ce soit voulu.
4. Planifiez des vérifications contrôlées périodiques pour les grands volumes si votre modèle de risque l’exige.
5. Corrigez les causes d’arrêts non propres : alimentation instable, noyaux/pilotes instables, contrôleurs surchauffés, câbles défectueux.

FAQ

1) Combien de temps devrait prendre un fsck ext4 sur Debian 13 ?

De quelques secondes (rejeu de journal) à plusieurs heures (scan complet). Pour des systèmes de fichiers multi-téraoctets sur HDD avec beaucoup de petits fichiers, des heures peuvent être normales. Pour SSD/NVMe, des heures sont suspectes sauf si le système de fichiers est énorme ou si le périphérique est en mauvaise santé.

2) Pourquoi fsck semble bloqué sans mises à jour de pourcentage ?

Certaines passes n’émettent pas fréquemment de progression, et les consoles de démarrage peuvent tamponner la sortie. Plus important, fsck peut être bloqué sur des E/S tout en « tournant ». Utilisez l’état du processus via ps et iostat -x pour différencier.

3) Puis-je annuler fsck ?

Vous pouvez, mais c’est généralement une mauvaise affaire. Interrompre une réparation peut laisser le système de fichiers dans un pire état. Si vous suspectez une défaillance matérielle, la bonne « annulation » est d’arrêter les écritures, imager le disque, et récupérer en sécurité.

4) Est-il sûr d’exécuter fsck sur un système de fichiers monté ?

Pour ext4, exécuter un fsck réparateur sur un système de fichiers monté n’est pas sûr. Utilisez -n uniquement pour une inspection en lecture seule si nécessaire, et planifiez une maintenance hors-ligne pour les vraies réparations.

5) Pourquoi Debian exécute-t-il fsck au démarrage ?

Parce que monter un système de fichiers corrompu en lecture-écriture peut étendre les dégâts. La vérification au démarrage est une garde-fou. Parfois elle est ennuyeuse. Elle reste préférable à la corruption silencieuse.

6) Mon serveur est virtualisé. Qu’est-ce qui change ?

La latence ment. Une VM peut afficher un « disque lent » parce que l’hôte est surchargé, le backend de stockage est dégradé, ou vous êtes en compétition avec des voisins bruyants. Les diagnostics côté VM aident toujours, mais vous aurez peut-être besoin d’une confirmation côté hôte pour boucler l’enquête.

7) Dois-je désactiver les vérifications automatiques pour les gros volumes de données ?

Souvent, oui — si vous les remplacez par des vérifications programmées et de la surveillance. Utilisez 0 dans le champ pass de fsck pour le montage de données dans /etc/fstab, gardez root vérifié, et lancez des fsck contrôlés dans une fenêtre.

8) Quelle est la différence entre le rejou du journal et un fsck complet ?

Le rejou du journal applique les transactions en attente du journal et est généralement rapide. Le fsck complet analyse les structures de métadonnées et peut prendre beaucoup de temps, surtout avec de nombreux inodes et entrées de répertoire.

9) fsck se termine, mais le système ne démarre toujours pas. Et maintenant ?

Vérifiez si le chargeur de démarrage ou l’initramfs manque des fichiers, si /etc/fstab référence un mauvais UUID, et si le disque sous-jacent continue à faire des erreurs. Un fsck « réussi » sur un disque en défaillance peut être temporaire.

10) XFS/Btrfs/ZFS ont-ils le même problème de fsck ?

Ils ont des modes de défaillance différents. XFS utilise xfs_repair (hors-ligne, peut être lourd). Btrfs a ses propres outils et peut être pénible sous certaines corruptions. ZFS est totalement différent (scrubs, checksumming). Le thème commun : la latence de stockage et les fautes matérielles rendent toute réparation lente.

Étapes suivantes qui ne vous feront pas perdre la nuit

Si fsck sur Debian 13 « prend une éternité », ne le traitez pas comme la météo. Traitez-le comme un moment de diagnostic.

1. Dans les 10 minutes : vérifiez dmesg, iostat -x, et SMART. Décidez si vous faite face à une corruption sur stockage sain ou une corruption parce que le stockage est en train d’échouer.
2. Si le matériel semble malade : arrêtez les tentatives de réparation répétées, protégez les données, remplacez le périphérique, puis réparez/restaurez.
3. Si le matériel semble sain : laissez fsck finir, mais corrigez la cause des arrêts non propres et réexaminez la politique de vérification au démarrage pour les gros volumes non-root.
4. Après la récupération : capturez le log fsck, ajustez les passes dans /etc/fstab de manière réfléchie, et établissez des baselines de durées de vérification pour que le prochain astreint n’ait pas à deviner.

Vous n’avez pas besoin d’aimer les vérifications de système de fichiers. Il suffit de cesser d’être surpris par elles.