Le système de fichiers Proxmox devient lecture seule : pourquoi et comment récupérer

Ce que « lecture seule » signifie réellement sur Proxmox

« Lecture seule » n’est pas une seule chose. Sur un hôte Proxmox vous pouvez avoir :

• Le système de fichiers racine (généralement ext4 ou ZFS root, parfois XFS) monté en lecture seule par le noyau après des erreurs.
• Un système de fichiers de données (dataset ZFS, ext4/XFS sur LVM, montage NFS/Ceph) passant en lecture seule alors que l’hôte reste inscriptible.
• pmxcfs (le système de fichiers de cluster Proxmox monté sur /etc/pve) refusant les écritures lorsqu’il n’y a pas de quorum ou en cas de problème de base locale.
• Un comportement applicatif en lecture seule qui ressemble à un problème de système de fichiers (par ex., dataset ZFS readonly=on, ou un backend de stockage retournant EROFS).

Le noyau bascule un point de montage en lecture seule quand il pense que poursuivre les écritures pourrait corrompre les métadonnées. Ce n’est pas Linux qui fait son cinéma ; c’est Linux qui refuse d’être complice.

Règle n°1 : identifiez quel point de montage est en lecture seule et ce qui génère le chemin d’erreur (VFS, pilote du système de fichiers, couche bloc, ou service de cluster). Si vous sautez cette étape, vous passerez une heure à remonter la mauvaise chose et vous aurez l’impression d’avoir été productif alors que rien n’aura changé.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : confirmer ce qui est en lecture seule et où les écritures échouent

• Est-ce / ? /var ? /etc/pve ? Un dataset ZFS comme rpool/data ? Un partage NFS monté ?
• Essayez une petite écriture dans le chemin en échec (ne « corrigez » rien encore). C’est une sonde.

Second : récupérez l’histoire du noyau avant qu’elle ne disparaisse

• dmesg -T et journalctl -k -b vous diront si le noyau a vu des erreurs d’E/S, une corruption du système de fichiers, une suspension de pool ZFS, ou un arrêt forcé.
• Cherchez : Buffer I/O error, EXT4-fs error, XFS (…): Corruption detected, blk_update_request, resets ata/nvme, ZFS: pool I/O suspended.

Troisième : décidez s’il s’agit d’un « stockage malade » ou d’un « système de fichiers malade »

• Stockage malade : erreurs d’E/S, timeouts, resets, avertissements SMART, erreurs média NVMe. Réparez le matériel/câblage/contrôleur d’abord. Lancer fsck sur un disque qui est en train de lâcher transforme une éraflure en amputation.
• Système de fichiers malade : santé du dispositif propre, mais métadonnées corrompues. Alors réparez (fsck/xfs_repair/zpool clear selon la pile).
• Cluster/quorum malade : seul /etc/pve est en lecture seule et les logs montrent une perte de quorum. C’est politique, pas physique.

Prenez une décision rapidement : stabiliser, préserver les preuves, puis réparer. Votre objectif est d’éviter les dégâts en cascade (disques VM, logs, bases) tout en rétablissant le service.

Pourquoi les systèmes de fichiers deviennent lecture seule (modes de panne réels)

1) Erreurs d’I/O disque réelles (la cause « réelle » la plus fréquente)

Lorsque la couche bloc ne peut pas compléter les écritures, les systèmes de fichiers répondent souvent en se remontant en lecture seule pour éviter des métadonnées à moitié écrites. Cela peut provenir de :

• Secteurs défectueux sur HDD ou usure NAND sur SSD
• Resets de contrôleur NVMe ou bugs de firmware
• Problèmes de câble SATA (oui, encore)
• Bugs de contrôleur RAID ou défauts de cache/batterie
• Perte d’alimentation provoquant un panic interne du périphérique

Sur Proxmox, le premier indice apparaît généralement dans dmesg bien avant que vous ne voyiez « lecture seule » au niveau du point de montage.

2) Corruption des métadonnées du système de fichiers (ext4/XFS)

ext4 a une politique de comportement en cas d’erreurs. Les valeurs par défaut courantes : remonter en lecture seule sur erreur. XFS a tendance à forcer l’arrêt si elle détecte une corruption. Les deux vous rendent service—mais pas de façon commode.

3) Problèmes de pool ZFS : I/O suspendues, vdevs faultés, ou disparitions de périphériques

ZFS ne « remonte » pas en lecture seule de la même manière qu’ext4. Il peut suspendre l’I/O pour protéger la cohérence lorsqu’il ne peut pas garantir les écritures. Du point de vue des VM, c’est similaire : les opérations se bloquent ou échouent, et Proxmox commence à journaliser des échecs de stockage.

4) Système de fichiers plein ou épuisement d’inodes (ressemble à de la lecture seule si vous nisez pas l’erreur)

Un système de fichiers plein affiche généralement No space left on device, pas lecture seule. Mais de nombreux outils et esprits humains interprètent « impossible d’écrire » comme « lecture seule ». Sur un hôte Proxmox, /var se remplit souvent à cause des logs, sauvegardes, dumps de crash, ou écritures incontrôlées de containers.

5) pmxcfs (/etc/pve) lecture seule à cause d’une perte de quorum

/etc/pve est un système de fichiers basé sur FUSE (pmxcfs). Quand le cluster perd le quorum, Proxmox vous protège d’un split-brain en mettant la configuration du cluster en lecture seule. Les gens confondent souvent cela avec une panne disque car le message d’erreur est identique.

6) « Optimisations » qui créent de la fragilité

Mise en cache d’écriture sans protection contre la perte d’alimentation, réglages agressifs de discard, désactivation des barrières, modes RAID exotiques, périphériques USB de démarrage bon marché… tout cela peut produire des remontages en lecture seule « surprenants » pendant une charge ou un incident d’alimentation. La surprise n’atteint que la personne qui l’a configuré.

Blague n°1 : Le stockage, c’est comme le parachutisme—la plupart du temps c’est ennuyeux, et les parties excitantes sont rarement répétables de façon agréable.

Faits intéressants et historique à utiliser

1. La filiation « errors=remount-ro » d’ext4 remonte à l’époque d’ext2/ext3 : si les métadonnées sont suspectes, arrêtez rapidement d’écrire pour préserver la récupérabilité.
2. XFS est né chez SGI pour des charges big‑iron ; son comportement de « force shutdown » est une posture volontaire « mieux vaut mort que corrompu ».
3. Le VFS Linux utilise EROFS (« Error Read-Only File System ») comme signal générique—donc des causes totalement différentes peuvent sembler identiques depuis l’espace utilisateur.
4. Le /etc/pve de Proxmox n’est pas « un répertoire » au sens habituel. C’est un magasin de configuration distribué exposé comme un système de fichiers via FUSE (pmxcfs).
5. Les règles de quorum sont plus anciennes que Proxmox : les systèmes distribués utilisent le vote majoritaire depuis des décennies pour éviter le split-brain. Proxmox le rend simplement très visible.
6. ZFS considère la corruption silencieuse comme un ennemi de première classe ; le modèle de sommes de contrôle bout à bout explique pourquoi il est apprécié en exploitation—et pourquoi il peut devenir strict quand les périphériques déraillent.
7. SMART n’a pas été conçu pour une prédiction parfaite ; c’est plutôt de la « météo » pour disques. Utile, mais pas magique.
8. Les caches d’écriture ont changé le jeu des pannes : les SSD et contrôleurs modernes peuvent accuser réception d’écritures avant leur durabilité. Sans protection contre la perte d’alimentation, c’est une taxe d’intégrité que vous payez plus tard.
9. Les systèmes de fichiers FUSE peuvent devenir « lecture seule » pour des raisons non liées aux disques, parce que le démon peut décider de refuser des écritures quand son modèle de cohérence est menacé.

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

Voici les tâches que j’exécute réellement quand un nœud Proxmox commence à refuser des écritures. Chaque tâche inclut : la commande, ce que la sortie signifie, et la décision suivante.

Tâche 1 : Prouver quel point de montage est en lecture seule

cr0x@server:~$ mount | egrep ' on / | on /var | on /etc/pve |type zfs|type ext4|type xfs'
/dev/mapper/pve-root on / type ext4 (ro,relatime,errors=remount-ro)
/dev/fuse on /etc/pve type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)

Signification : la racine est montée (ro,...). /etc/pve est encore rw.

Décision : traitez cela comme un problème de système de fichiers hôte, pas de quorum. Passez aux logs noyau et à la santé du stockage immédiatement.

Tâche 2 : Tenter une écriture contrôlée dans le chemin en échec

cr0x@server:~$ touch /root/.rw-test
touch: cannot touch '/root/.rw-test': Read-only file system

Signification : l’erreur est réelle et provient du VFS/FS, pas des permissions.

Décision : arrêtez les écritures non essentielles (sauvegardes, tempêtes de logs), et rassemblez des preuves avant de redémarrer.

Tâche 3 : Lire les messages du noyau pour le déclencheur

cr0x@server:~$ dmesg -T | tail -n 40
[Thu Dec 26 10:41:09 2025] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Thu Dec 26 10:41:09 2025] blk_update_request: I/O error, dev sda, sector 312492800 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 10:41:09 2025] EXT4-fs error (device dm-0): ext4_journal_check_start:83: Detected aborted journal
[Thu Dec 26 10:41:09 2025] EXT4-fs (dm-0): Remounting filesystem read-only

Signification : cela a commencé comme une erreur au niveau bloc (dev sda) qui a ensuite causé l’abandon du journal ext4 et le remontage en ro.

Décision : supposez un problème matériel jusqu’à preuve du contraire. Faites SMART, vérifiez câblage/contrôleur ; évitez fsck tant que le périphérique n’est pas stable.

Tâche 4 : Confirmer le boot actuel et obtenir des logs persistants

cr0x@server:~$ journalctl -k -b | egrep -i 'error|ext4|xfs|nvme|ata|timeout|reset|zfs|I/O' | tail -n 60
Dec 26 10:41:09 server kernel: blk_update_request: I/O error, dev sda, sector 312492800 op 0x1:(WRITE)
Dec 26 10:41:09 server kernel: EXT4-fs error (device dm-0): ext4_journal_check_start: Detected aborted journal
Dec 26 10:41:09 server kernel: EXT4-fs (dm-0): Remounting filesystem read-only

Signification : même histoire que dmesg, mais maintenant dans le journal (utile après un redémarrage).

Décision : poursuivez par des vérifications de santé du périphérique ; planifiez une fenêtre de maintenance si le disque sous-jacent est défaillant.

Tâche 5 : Identifier la pile de périphériques bloc (dm-0 → LVM → disque physique)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,UUID
NAME           TYPE   SIZE FSTYPE      MOUNTPOINTS                UUID
sda            disk  1.8T
├─sda1         part  1007K
├─sda2         part     1G vfat        /boot/efi                 2B1A-9C3D
└─sda3         part   1.8T LVM2_member                          1dGk2A-...
  ├─pve-root   lvm     96G ext4        /                         4d9a7a0e-...
  ├─pve-swap   lvm      8G swap        [SWAP]                    0f19...
  └─pve-data   lvm    1.7T LVM2_member
    └─pve-vm--data-lvpool lvm 1.7T

Signification : le système de fichiers root repose sur le volume logique LVM pve-root soutenu par sda3.

Décision : vérifiez d’abord le disque physique (/dev/sda). Une belle pile LVM ne sauvera pas un disque en train de mourir.

Tâche 6 : Vérifier l’état SMART (SATA/SAS) pour savoir si le disque ment

cr0x@server:~$ smartctl -a /dev/sda
SMART overall-health self-assessment test result: FAILED!
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always   FAILING_NOW 2048
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       128
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       128

Signification : ce disque ne se contente pas d’être « dégradé », il échoue activement. Les secteurs réalloués et en attente corrèlent fortement avec les erreurs d’I/O.

Décision : ne faites plus confiance à ce périphérique. Priorisez l’évacuation des données et le remplacement. N’exécutez pas de réparations intensives en écriture sauf si nécessaire.

Tâche 7 : Santé NVMe (si vous démarrez depuis NVMe)

cr0x@server:~$ nvme smart-log /dev/nvme0
critical_warning                    : 0x00
media_errors                        : 12
num_err_log_entries                 : 58
percentage_used                     : 87%

Signification : forte usure (percentage_used) et erreurs média enregistrées. Pas automatiquement fatal, mais pas non plus à ignorer.

Décision : planifiez un remplacement et vérifiez le firmware/thermique. Si le système de fichiers est déjà remonté en ro, traitez cela en urgence.

Tâche 8 : Vérifier si /etc/pve est le point en lecture seule (détection de quorum)

cr0x@server:~$ touch /etc/pve/.pmxcfs-test
touch: cannot touch '/etc/pve/.pmxcfs-test': Read-only file system

Signification : pmxcfs refuse les écritures (souvent quorum, parfois problème pmxcfs).

Décision : faites des vérifications de cluster, pas des vérifications de disque, sauf si d’autres montages ont échoué aussi.

Tâche 9 : Santé du cluster et quorum

cr0x@server:~$ pvecm status
Quorum information
------------------
Date:             Thu Dec 26 11:02:18 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          No

Signification : pas de quorum. Proxmox protégera les écritures de configuration du cluster.

Décision : réparez le réseau corosync / ramenez les nœuds / ajustez les votes attendus pour une opération d’urgence (prudemment). N’essayez pas de « chmod » votre sortie.

Tâche 10 : Vérifier les services pmxcfs / corosync

cr0x@server:~$ systemctl status pve-cluster corosync --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Active: active (running)
● corosync.service - Corosync Cluster Engine
     Active: active (running)

Signification : les services sont en cours, mais le quorum peut être perdu. Ne confondez pas « active » avec « sain ».

Décision : dépannez la connectivité et les votes ; validez pvecm status après vos changements.

Tâche 11 : Vérification rapide de ZFS (si vous utilisez ZFS)

cr0x@server:~$ zpool status -x
pool 'rpool' is DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
action: Replace the device using 'zpool replace'.

Signification : un membre de vdev est manquant ou illisible. Sur des pools mirror/raidz, vous pouvez encore fonctionner, mais vous êtes en sursis.

Décision : identifiez le périphérique manquant, vérifiez le câblage/backplane, et remplacez. Si l’I/O est suspendue, priorisez la résolution sécurisée de cette condition.

Tâche 12 : Statut ZFS détaillé avec erreurs et mappage des périphériques

cr0x@server:~$ zpool status -v rpool
  pool: rpool
 state: DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
config:

        NAME                        STATE     READ WRITE CKSUM
        rpool                       DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       UNAVAIL      0     0     0  cannot open

errors: No known data errors

Signification : un membre du miroir a disparu. Pas encore d’erreurs de checksum, mais la résilience est réduite à zéro redondance.

Décision : traitez cela comme un incident. Trouvez pourquoi le périphérique est UNAVAIL (reset HBA ? backplane ? SSD mort). Remplacez puis lancez un scrub.

Tâche 13 : Chercher un événement ZFS « I/O suspendue » dans les logs

cr0x@server:~$ journalctl -k -b | egrep -i 'zfs|suspend|zio|I/O' | tail -n 40
Dec 26 10:55:01 server kernel: ZFS: vdev IO failure, zio pipeline stalled
Dec 26 10:55:01 server kernel: ZFS: pool rpool has encountered an uncorrectable I/O failure and has been suspended.

Signification : ZFS a suspendu le pool pour prévenir d’autres dégâts. Les écritures peuvent échouer ou se bloquer.

Décision : arrêtez les écritures VM/CT, assurez la stabilité du chemin matériel, puis effacez/remplacez selon le cas. Redémarrer sans corriger le matériel peut créer des boucles.

Tâche 14 : Détecter rapidement « c’est juste plein »

cr0x@server:~$ df -hT /
Filesystem          Type  Size  Used Avail Use% Mounted on
/dev/mapper/pve-root ext4   94G   94G     0 100% /

Signification : la racine est pleine. Cela seul ne devrait pas remonter en ro, mais provoquera des échecs d’écriture généralisés.

Décision : libérez de l’espace en sécurité (nettoyage des logs, suppression d’anciens kernels, vider les caches), puis réévaluez. Si vous voyez aussi des erreurs ext4, le disque plein peut être un symptôme (ex. : spam de logs dû à un matériel défaillant).

Tâche 15 : Confirmer la politique d’erreur ext4 et les options de montage

cr0x@server:~$ tune2fs -l /dev/mapper/pve-root | egrep -i 'Filesystem state|Errors behavior|Last error'
Filesystem state:         clean
Errors behavior:          Remount read-only
Last error time:          Thu Dec 26 10:41:09 2025

Signification : ext4 est configuré pour remonter en ro sur erreurs ; l’heure de la dernière erreur correspond à l’incident.

Décision : planifiez un fsck hors ligne après stabilisation du matériel. Ne changez pas le comportement d’erreur pour « réparer » ; c’est comme retirer les piles de l’alarme incendie parce qu’elle sonne.

Tâche 16 : Confirmer les détails d’arrêt forcé XFS (si XFS)

cr0x@server:~$ journalctl -k -b | egrep -i 'xfs|shutdown|metadata|corrupt' | tail -n 40
Dec 26 10:39:12 server kernel: XFS (dm-0): Corruption detected. Unmount and run xfs_repair
Dec 26 10:39:12 server kernel: XFS (dm-0): xfs_do_force_shutdown(0x2) called from xfs_reclaim_inodes+0x2b0/0x2f0

Signification : XFS a détecté une corruption et a forcé l’arrêt pour prévenir d’autres dégâts.

Décision : planifiez une fenêtre pour démonter et exécuter xfs_repair (souvent depuis un mode rescue). Encore une fois : vérifiez d’abord le matériel.

Voilà le cœur du diagnostic. Maintenant parlons de la récupération sans empirer la situation.

Récupération par pile de stockage : ext4/XFS, ZFS, LVM, pmxcfs

Cas A : ext4 root ou système de fichiers de données remonté en lecture seule

ext4 passe en lecture seule quand il détecte une incohérence interne (souvent déclenchée par des erreurs d’I/O). Vos priorités :

1. Arrêter les services intensifs en écriture pour réduire le churn.
2. Capturer les logs (noyau et syslog).
3. Confirmer la santé du stockage sous-jacent (SMART, resets dmesg).
4. Réparer hors ligne (fsck) après avoir confiance dans la couche bloc.

Tenter de remonter en lecture-écriture (uniquement temporaire)

Si le noyau a remonté ro à cause d’erreurs ext4, remonter rw peut échouer — ou réussir brièvement puis retomber. Considérez cela comme « récupérer des logs et configs critiques », pas « reprendre le service ».

cr0x@server:~$ mount -o remount,rw /
mount: /: cannot remount /dev/mapper/pve-root read-write, is write-protected.

Signification : le noyau refuse rw parce que le système de fichiers est dans un état d’erreur.

Décision : vous devez réparer hors ligne. Ne combattez pas le noyau. Il gagnera, et vous perdrez des données.

Préparer un fsck hors ligne (approche relativement sûre)

Vous ne pouvez généralement pas fsck le système de fichiers racine monté. Planifiez de démarrer en environnement de secours ou en mode mono‑utilisateur avec la racine démontée.

En termes Proxmox, cela signifie souvent : démarrer depuis un ISO/média virtuel IPMI, ou utiliser la récupération grub si vous savez ce que vous faites.

Une fois en rescue, exécutez :

cr0x@server:~$ fsck.ext4 -f -y /dev/mapper/pve-root
e2fsck 1.47.0 (5-Feb-2023)
/dev/mapper/pve-root: recovering journal
/dev/mapper/pve-root: Clearing orphaned inode 131082
/dev/mapper/pve-root: FIXED.

Signification : le journal a été récupéré ; les inodes orphelins corrigés ; fsck indique des réparations.

Décision : redémarrez et surveillez les logs. Si les erreurs réapparaissent, le chemin disque est toujours défaillant ou vous avez des problèmes de RAM/contrôleur.

Quand fsck est la mauvaise première étape

Si SMART échoue ou que dmesg montre des resets/timeouts, fsck peut accélérer l’échec à cause des lectures/écritures intensives. Dans ce cas :

• Imagez/copiez ce que vous pouvez (disques VM, configs) vers un périphérique sain.
• Remplacez le matériel.
• Puis réparez si nécessaire.

Cas B : XFS forcé en arrêt

XFS se répare avec xfs_repair. Il doit s’exécuter avec le système de fichiers démonté. Si c’est le root, vous êtes de nouveau en mode rescue.

cr0x@server:~$ xfs_repair /dev/mapper/pve-root
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
Phase 7 - verify and correct link counts...
done

Signification : le journal a été réinitialisé et les métadonnées corrigées.

Décision : redémarrez, puis testez des charges. Si la corruption revient, c’est souvent matériel (RAM, contrôleur, disque) plutôt que XFS « fragile ».

Cas C : Problème de pool ZFS (degraded, faulted, I/O suspendues)

ZFS n’est pas timide. S’il estime qu’il ne peut pas engager les écritures en toute sécurité, il peut suspendre l’I/O. C’est alors que Proxmox semble hanté : les disques VM se bloquent, les tâches n’aboutissent pas, et vous avez des timeouts partout.

Étape 1 : status, ne devinez pas

cr0x@server:~$ zpool status -v
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
errors: Permanent errors have been detected in the following files:
        rpool/data/vm-101-disk-0

Signification : vous avez des erreurs permanentes affectant un disque VM. ZFS vous dit qu’il n’a pas pu réparer à partir de la redondance.

Décision : arrêtez cette VM, restaurez depuis une sauvegarde/réplica. Ne « scrubez » pas plus fort ; scrub n’inventera pas des blocs manquants.

Étape 2 : remplacer le périphérique manquant/faulted (exemple)

cr0x@server:~$ zpool replace rpool ata-SAMSUNG_SSD_2 /dev/disk/by-id/ata-SAMSUNG_SSD_NEW

Signification : ZFS commence à resilver sur le nouveau périphérique.

Décision : surveillez la progression du resilver et la charge système. En production, vous voudrez peut‑être arrêter les migrations et les sauvegardes intensives.

Étape 3 : effacer les erreurs après correction matérielle

cr0x@server:~$ zpool clear rpool

Signification : efface les compteurs d’erreurs ; ne « répare » pas les données seul.

Décision : lancez un scrub pour valider et réparer à partir de la redondance.

Étape 4 : scrub et interprétation des résultats

cr0x@server:~$ zpool scrub rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
scan: scrub repaired 0B in 00:12:31 with 0 errors on Thu Dec 26 12:03:44 2025

Signification : le scrub n’a trouvé aucune erreur (bien). Si des données ont été réparées, vous verrez des octets réparés ; si impossible, vous verrez des erreurs.

Décision : si les erreurs persistent : vérifiez le câblage/HBA, et envisagez un test mémoire (ZFS révèle bien la RAM défectueuse).

Cas D : Problèmes LVM ou device-mapper provoquant un comportement en lecture seule

Parfois le système de fichiers est innocent ; le périphérique bloc sous-jacent bascule en état d’erreur. Vérifiez les messages dm et LVM :

cr0x@server:~$ dmsetup info -C
Name             Maj Min Stat Open Targ Event  UUID
pve-root         252   0 L--w   1    1      0  LVM-...

Signification : les indicateurs Stat peuvent donner des indices sur l’état du périphérique (cela varie). Plus important : croisez avec les logs noyau pour « device mapper: thin: … » ou « I/O error on dm-0 ».

Décision : si le metadata du thin-pool est plein ou corrompu, vous avez besoin de correctifs spécifiques LVM-thin et probablement d’une indisponibilité. N’improvisez pas.

Cas E : /etc/pve en lecture seule (pmxcfs / quorum)

C’est le piège classique Proxmox : tout le reste est inscriptible, mais vous ne pouvez pas éditer une config VM, la config de stockage, ou ajouter un nœud. L’erreur indique lecture seule. Les gens remplacent le disque alors que le cluster n’a juste pas le quorum.

Confirmer le montage pmxcfs et le quorum

cr0x@server:~$ mount | grep /etc/pve
pve-cluster on /etc/pve type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

cr0x@server:~$ pvecm status | egrep 'Quorate|Nodes|Expected votes|Total votes'
Nodes:            2
Expected votes:   3
Total votes:      2
Quorate:          No

Signification : le montage pmxcfs indique rw, mais l’état du cluster n’est pas quoré ; Proxmox refusera quand même les écritures de configuration.

Décision : restaurez le quorum en ramenant les nœuds ou en réparant le réseau corosync. Ne modifiez les votes attendus qu’en connaissance de cause pour éviter le split-brain.

Urgence : définir expected votes (à utiliser avec respect)

cr0x@server:~$ pvecm expected 2

Signification : vous dites à corosync d’attendre moins de votes pour que les nœuds restants deviennent quorés.

Décision : faites cela seulement quand vous êtes sûr que les nœuds manquants ne reviendront pas écrire une configuration divergente. C’est un levier de « remettre en production » d’urgence, pas une commodité quotidienne.

Blague n°2 : Le quorum, c’est la réunion d’entreprise où rien n’est approuvé à moins que suffisamment de personnes soient présentes, et d’une certaine façon c’est encore mieux que le chaos.

Trois mini-récits tirés de la vie en entreprise

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’équipe a vu « Read-only file system » en éditant une config VM. Naturellement, ils ont accusé le SSD de démarrage. Quelqu’un a ouvert un ticket pour remplacer le disque. Pendant ce temps, le nœud servait toujours des VM sans problème et SMART était propre.

Un administrateur senior a essayé de créer un fichier dans /tmp et ça a marché. Il a essayé la même chose dans /etc/pve et ça a échoué. Ce détail aurait dû clore le débat, mais l’hypothèse était déjà ancrée : « lecture seule = disque ».

Ils ont fini par exécuter pvecm status et ont découvert que le cluster n’était pas quoré après un changement réseau : le trafic corosync passait sur la même interface agrégée qu’un VLAN de sauvegarde bruyant, et la perte de paquets multicast/UDP faisait osciller l’appartenance. pmxcfs a protégé l’état du cluster en refusant les écritures. Exactement ce pourquoi il existe.

La correction fut ennuyeuse : déplacer corosync sur son propre VLAN et vérifier MTU et pertes de paquets. Aucun swap de disque nécessaire. La meilleure ligne du postmortem : « Nous avons traité un problème de système distribué comme un problème de disque. » C’est la mauvaise hypothèse en une phrase.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe voulait un stockage VM plus rapide. Ils ont activé la mise en cache d’écriture agressive sur un contrôleur RAID, et pour faire bonne mesure ont désactivé les barrières parce que « nous avons une batterie ». Les benchmarks étaient magnifiques. Tout le monde a applaudi. Quelqu’un a mis les graphes dans une présentation, et vous savez alors que c’est sérieux.

Des mois plus tard, un événement de maintenance a provoqué une brève perturbation d’alimentation. La batterie du cache RAID existait mais n’était pas saine ; elle envoyait des avertissements que personne ne surveillait. Le contrôleur accusait réception d’écritures qui n’étaient pas durables, et après le redémarrage, le système de fichiers hôte est apparu avec des problèmes de journal. ext4 l’a détecté et a remonté la racine en lecture seule en plein boot.

La récupération fut pénible : boot en rescue, fsck, puis des jours à traquer des symptômes de corruption au niveau VM. Tout n’a pas été perdu, mais la confiance a été affectée. L’« optimisation » a sauvé des millisecondes et coûté des week-ends.

Le changement durable n’a pas été un réglage de performance ; c’était de la gouvernance : toute modification touchant l’ordre des écritures nécessitait un modèle explicite de perte d’alimentation et une surveillance de l’état batterie/flash du contrôleur. La vitesse, c’est bien. La vitesse avec mensonge, c’est comment on se retrouve à faire du développement de carrière non désiré.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre équipe utilisait Proxmox sur des miroirs ZFS, maintenait des scrubs hebdomadaires, et faisait quelque chose de profondément peu glamour : tester les restaurations. Pas une fois. Régulièrement. Les sauvegardes n’étaient pas une case à cocher, elles faisaient partie du rythme opérationnel.

Un matin, un nœud a commencé à journaliser des erreurs média NVMe. ZFS a signalé un périphérique qui devenait instable, mais le pool est resté en ligne grâce au mirroring. L’équipe n’a pas attendu le grand effondrement. Ils ont migré les VM les plus chargées hors du nœud, remplacé le NVMe, et resilveré.

Pendant le resilver, un disque VM a présenté une erreur permanente sur un bloc précis. C’est le titre cauchemardesque, sauf que ce ne l’était pas. Ils ont arrêté la VM, restauré depuis la sauvegarde de la nuit précédente, et ont poursuivi. La fenêtre d’indisponibilité a été limitée à une charge et le rayon d’impact est resté petit.

La manœuvre gagnante n’a pas été une commande astucieuse. C’était la mémoire musculaire pratiquée : scrub, surveiller, migrer, remplacer, restaurer. Pas de drame. Pas d’archéologie nocturne dans dmesg. L’ennuyeux a gagné parce que l’ennuyeux était préparé.

Erreurs courantes : symptômes → cause racine → correction

1) « Impossible d’éditer la config VM » → problème pmxcfs/quorum → corriger le quorum du cluster

• Symptômes : les écritures échouent seulement sous /etc/pve ; les VM tournent toujours ; les vérifications disque semblent propres.
• Cause racine : cluster non quoré, ou instabilité corosync.
• Correction : pvecm status, restaurez la connectivité des nœuds ; en urgence, ajustez les votes attendus de manière délibérée. Puis validez les écritures sous /etc/pve.

2) Le système de fichiers root est passé en ro après des erreurs I/O → disque/câble/HBA en fin de vie → corriger le chemin matériel d’abord

• Symptômes : blk_update_request, timeouts, resets ATA, resets NVMe ; abandon du journal ext4.
• Cause racine : chemin de périphérique bloc instable.
• Correction : logs SMART/NVMe ; reseat/remplacer le câble ; mettre à jour le firmware ; remplacer le périphérique. Ensuite seulement fsck/réparation.

3) Pool ZFS « suspendu » → erreurs répétées de périphérique → arrêter les écritures, remplacer, clear, scrub

• Symptômes : tâches qui se bloquent ; logs ZFS indiquant pool suspendu ; zpool status montre UNAVAIL/FAULTED.
• Cause racine : ZFS a rencontré des I/O irréparables et s’est suspendu pour protéger la cohérence.
• Correction : stabiliser le matériel ; remplacer le vdev défaillant ; zpool clear ; scrub. Restaurer les disques VM affectés si des erreurs permanentes existent.

4) « Lecture seule » mais en réalité disque plein → croissance des logs/sauvegardes → libérer de l’espace, corriger la source

• Symptômes : écritures échouent ; df -h montre 100% ; logs énormes.
• Cause racine : système de fichiers plein ou épuisement d’inodes.
• Correction : supprimer les gros coupables (/var/log, vieux ISOs, anciens kernels), faire la rotation des logs, déplacer les sauvegardes, et ajouter des seuils de surveillance.

5) Boucle de réparation : fsck « répare » mais ro revient → erreurs sous-jacentes continuent → arrêter et traiter la cause

• Symptômes : après reboot/réparation, en quelques heures ça remonte en ro à nouveau.
• Cause racine : matériel défaillant, RAM défectueuse, contrôleur instable, ou problèmes d’alimentation.
• Correction : diagnostics matériels, memtest en fenêtre de maintenance, mises à jour firmware, et revue du chemin d’alimentation (PSU/UPS).

6) Essayer de forcer des montages rw en production → plus de corruption → accepter l’indisponibilité et réparer correctement

• Symptômes : récupération intermittente avec mount -o remount,rw, puis aggravation des erreurs.
• Cause racine : traiter le symptôme ; ignorer la protection d’intégrité.
• Correction : planifier une coupure, réparer hors ligne, restaurer depuis sauvegarde si nécessaire. La physique ne se négocie pas.

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

Checklist A : Quand le système de fichiers racine de l’hôte Proxmox est en lecture seule

1. Stabiliser : mettre en pause les tâches lourdes. Si des VM tournent, arrêter sauvegardes/migrations. Éviter les tempêtes de logs.
2. Identifier les montages : confirmer quel montage est ro (mount, findmnt).
3. Collecter des preuves : dmesg -T, journalctl -k -b, stocker des copies hors hôte si possible.
4. Vérifier la santé du stockage : smartctl ou nvme smart-log ; noter les resets/timeouts.
5. Décider :
   • Si matériel malade : évacuer les données et remplacer le matériel.
   • Si matériel propre : planifier fsck/xfs_repair hors ligne.
6. Réparer hors ligne : démarrer en rescue, exécuter l’outil de réparation du système de fichiers, redémarrer.
7. Valider : surveiller les logs pour réapparition ; exécuter une charge contrôlée ; planifier un suivi.

Checklist B : Quand seul /etc/pve se comporte en lecture seule

1. Vérifier la portée : test d’écriture dans /tmp et /etc/pve.
2. Vérifier le quorum : pvecm status.
3. Vérifier la santé corosync : perte de paquets, VLAN, cohérence MTU, mode de bonding, configuration des switchs.
4. Rétablir le quorum : ramener les nœuds, réparer le réseau. N’utiliser expected votes qu’en levier d’urgence.
5. Valider : créer/éditer un changement de configuration sans risque (ou toucher un fichier) sous /etc/pve.

Checklist C : Quand ZFS est mécontent (degraded/suspended/errors)

1. Obtenir le statut : zpool status -v et le capturer.
2. Arrêter les dégâts : mettre en pause les écritures VM si le pool est suspendu ou génère des erreurs.
3. Confirmer le mappage des périphériques : cartographier by-id vers baie physique ; vérifier les logs HBA/backplane.
4. Remplacer/réparer le périphérique : reseater, remplacer, zpool replace selon le cas.
5. Clear et scrub : zpool clear, puis zpool scrub.
6. Gérer les erreurs permanentes : restaurer les disques VM affectés depuis sauvegarde/réplica ; ne pas feindre que rien ne s’est passé.

Un principe opérationnel unique (à mémoriser)

« Réparer » n’est pas un objectif ; « rétablir le service sans corrompre les données » l’est. Beaucoup d’incidents surviennent parce que quelqu’un a optimisé pour le premier.

Une citation, parce que c’est la chose la plus proche d’une écriture sacrée que notre domaine ait :

« L’espoir n’est pas une stratégie. » — Gen. Gordon R. Sullivan

FAQ

1) Pourquoi Linux remonte ext4 en lecture seule au lieu de planter ?

Parce que continuer à écrire après une corruption des métadonnées peut rendre la récupération impossible. Remonter en ro est un mouvement de confinement : préserver ce qui reste cohérent.

2) Puis-je simplement exécuter mount -o remount,rw / et continuer ?

Parfois cela fonctionne brièvement. Si le noyau a signalé des erreurs ext4, il échouera souvent. Même si ça marche, vous écrivez sur un système de fichiers qui a déjà admis qu’il ne peut pas garantir la cohérence. Utilisez remount rw uniquement pour extraire des données ou des logs, pas comme « solution ».

3) Si /etc/pve est en lecture seule, cela signifie-t-il que mon disque est cassé ?

Pas nécessairement. pmxcfs peut bloquer les écritures à cause d’une perte de quorum ou d’un état de cluster. Testez les écritures ailleurs (comme /tmp), puis vérifiez pvecm status.

4) Quelle est la façon la plus rapide de différencier « problème de quorum » vs « problème disque » ?

Si seul /etc/pve échoue aux écritures et que le reste du système est inscriptible, c’est généralement un problème de quorum/pmxcfs. Si root ou /var est en ro, c’est habituellement système de fichiers/matériel. Confirmez avec mount et pvecm status.

5) ZFS indique « permanent errors ». Un scrub peut-il réparer ça ?

Non. « Permanent errors » signifie que ZFS n’a pas pu reconstruire les données à partir de la redondance. Vous devez restaurer le fichier/volume affecté depuis une sauvegarde ou un réplica.

6) Le SMART du disque semble correct, mais ext4 s’est remonté en ro. Que peut-il y avoir d’autre ?

SMART peut rater des défaillances transitoires ou des pannes au niveau du chemin. Cherchez des resets SATA/NVMe, des erreurs de contrôleur, des câbles/backplanes défectueux, des problèmes d’alimentation, et (occasionnellement) de la RAM défectueuse.

7) Dois-je redémarrer immédiatement quand je vois lecture seule ?

Pas aveuglément. D’abord collectez les logs (dmesg, journalctl) et vérifiez l’étendue de la panne. Redémarrer peut effacer les meilleures preuves, et si le matériel est défaillant, transformer un système chancelant en système mort.

8) Comment prévenir que cela ne se reproduise ?

Vous n’empêchez pas toutes les pannes. Vous réduisez la surprise et le rayon d’impact : surveillez SMART/NVMe, surveillez dmesg pour les resets, gardez de l’espace libre, scrubez ZFS, testez les restaurations, et isolez le réseau corosync.

9) Ext4 ou ZFS est‑il « meilleur » pour éviter les incidents lecture seule ?

Ils échouent différemment. ext4 remonte souvent en ro lors d’erreurs détectées ; ZFS tient bon jusqu’à un certain point puis devient strict (suspend l’I/O) et fournit d’excellents diagnostics. Choisissez selon votre maturité opérationnelle : ZFS récompense la discipline ; ext4 est plus simple mais moins explicite.

Prochaines étapes à entreprendre réellement

Si vous êtes en plein incident en ce moment :

1. Exécutez le playbook de diagnostic rapide : identifiez le montage, lisez les logs noyau, décidez « stockage vs système de fichiers vs quorum ».
2. Si vous voyez des erreurs I/O : considérez le matériel coupable jusqu’à preuve du contraire. Récupérez logs SMART/NVMe et planifiez un remplacement.
3. Si c’est des métadonnées ext4/XFS : planifiez une fenêtre de réparation hors ligne. Ne « remontez pas et priez ».
4. Si c’est /etc/pve : restaurez le quorum. Réparez le réseau corosync. Ne remplacez pas de disques pour résoudre un problème de vote.
5. Si c’est ZFS : interprétez zpool status -v littéralement. Remplacez les périphériques défaillants, scrubez, et restaurez tout ce qui a des erreurs permanentes.

Puis, après le rétablissement du service, faites le travail peu sexy : ajoutez de la surveillance pour les erreurs I/O noyau et les resets de périphériques, alertez sur l’usure des disques/erreurs média, imposez des seuils d’espace libre sur / et /var, et traitez corosync comme le plan de contrôle qu’il est. La production ne récompense pas les héros. Elle récompense les systèmes qui échouent de façon prévisible et se remettent vite.