Le 14/09, le moteur Longhorn de pi2, saturé en mémoire, a journalisé R/W Timeout. No response received in 8s. Les écritures sont ensuite revenues au noyau en critical medium error (cmd_age=23s), et ext4 a abandonné son journal sur quatre volumes : MinIO, loki, url-shortener et prometheus-server.
La mémoire de pi2 est soulagée depuis ce matin (factory#58 : 2,6 Gi rendus). Ce réglage retire le mécanisme lui-même, pas seulement le terrain.
Accord du fondateur : « Oui, après avoir soulagé pi2 ».
Le réglage
engine-replica-timeout (Helm : defaultSettings.engineReplicaTimeout), 8 → 20 s.
« The time in seconds a v1 engine will wait for a response from a replica before marking it as failed. Values between 8 and 30 are allowed. » (défaut 8) ;
« The engine replica timeout is only in effect while there are I/O requests outstanding. » ;
« A V1 engine marks the last active replica as failed only after twice the configured number of seconds (timeout value x 2) have passed. »
Pourquoi 20 et pas 30 : le dernier réplica n'est déclaré mort qu'au double. Le délai SCSI du noyau sur les disques Longhorn vaut 60 s (relevé sur les 3 Pi : /sys/dev/block/<maj:min>/device/timeout). Avec 30, on atteindrait 60 s, soit le délai du noyau lui-même : c'est le noyau qui abandonnerait la commande et renverrait l'erreur. Avec 20, on reste à 40 s, sous les 60.
Le prix
Une vraie panne de réplica met plus longtemps à être constatée : jusqu'à 20 s au lieu de 8, et 40 s au lieu de 16 pour le dernier. Pendant ce temps, les écritures du volume restent suspendues.
En échange, une lenteur passagère de 8 à 20 s ne fait plus sortir un réplica.
Il ne vaut que pour les moteurs démarrés après : chaque moteur reçoit la valeur en drapeau à son lancement (--engine-replica-timeout 8, relevé dans ps sur pi3). Les volumes déjà attachés gardent 8 s jusqu'à leur prochain rattachement. Aucun rattachement n'est forcé par cette PR.
Ce qui change
playbooks/system/k3s_config.yml : la valeur est ajoutée au valuesContent du HelmChart longhorn-install.
La tâche reçoit le tag longhorn pour être rejouée seule.
⚠ Piège existant, relevé en passant : joué sans tag, ce playbook exécute aussi la pièce « redeploy traefik » sur localhost, qui supprime le Deployment traefik et le Job helm-install-traefik dans le contexte kubectl COURANT, et celui-ci n'est pas forcément le homelab. Le commentaire ajouté le dit.
Vérifications faites avant
Rendu Helm : helm template longhorn-1.9.1.tgz avant/après ne diffère que d'une ligne, engine-replica-timeout: 20 dans la ConfigMap longhorn-default-setting. Aucune annotation de somme de contrôle : aucun pod n'est recréé.
Release en place : helm get manifest longhorn-install est identique au rendu « avant », hors hooks. La mise à niveau n'emporte donc aucune dérive cachée.
Manifeste réellement posé sur pi1 : identique au dépôt.
--list-tasks --tags longhorn : seule la tâche Longhorn, plus l'add_host en always. La pièce traefik n'a aucune tâche sélectionnée.
--check --diff : un seul changement, les lignes ci-dessus dans /var/lib/rancher/k3s/server/manifests/longhorn-install.yaml.
Ensuite : le helm-controller de k3s rejoue la release (révision 2, hooks pre-upgrade/post-upgrade de Longhorn), puis on relit settings.longhorn.io/engine-replica-timeout.
## Pourquoi (arcodange-org/tools#49, #52)
Le 14/09, le moteur Longhorn de pi2, saturé en mémoire, a journalisé `R/W Timeout. No response received in 8s`. Les écritures sont ensuite revenues au noyau en `critical medium error` (`cmd_age=23s`), et ext4 a abandonné son journal sur quatre volumes : MinIO, loki, url-shortener et prometheus-server.
La mémoire de pi2 est soulagée depuis ce matin (factory#58 : 2,6 Gi rendus). Ce réglage retire le **mécanisme** lui-même, pas seulement le terrain.
Accord du fondateur : « Oui, après avoir soulagé pi2 ».
## Le réglage
**`engine-replica-timeout`** (Helm : `defaultSettings.engineReplicaTimeout`), **8 → 20 s**.
Doc Longhorn v1.9.1, [Settings Reference](https://longhorn.io/docs/1.9.1/references/settings/) :
- « The time in seconds a v1 engine will wait for a response from a replica before marking it as failed. Values between 8 and 30 are allowed. » (défaut 8) ;
- « The engine replica timeout is only in effect while there are I/O requests outstanding. » ;
- « A V1 engine marks the last active replica as failed only after twice the configured number of seconds (timeout value x 2) have passed. »
**Pourquoi 20 et pas 30** : le dernier réplica n'est déclaré mort qu'au double. Le délai SCSI du noyau sur les disques Longhorn vaut **60 s** (relevé sur les 3 Pi : `/sys/dev/block/<maj:min>/device/timeout`). Avec 30, on atteindrait 60 s, soit le délai du noyau lui-même : c'est le noyau qui abandonnerait la commande et renverrait l'erreur. Avec 20, on reste à 40 s, sous les 60.
## Le prix
- **Une vraie panne de réplica met plus longtemps à être constatée** : jusqu'à 20 s au lieu de 8, et 40 s au lieu de 16 pour le dernier. Pendant ce temps, les écritures du volume restent **suspendues**.
- En échange, une lenteur passagère de 8 à 20 s ne fait plus sortir un réplica.
- **Il ne vaut que pour les moteurs démarrés après** : chaque moteur reçoit la valeur en drapeau à son lancement (`--engine-replica-timeout 8`, relevé dans `ps` sur pi3). Les volumes déjà attachés gardent 8 s jusqu'à leur prochain rattachement. **Aucun rattachement n'est forcé par cette PR.**
## Ce qui change
- `playbooks/system/k3s_config.yml` : la valeur est ajoutée au `valuesContent` du HelmChart `longhorn-install`.
- La tâche reçoit le tag **`longhorn`** pour être rejouée seule.
- ⚠ **Piège existant, relevé en passant** : joué sans tag, ce playbook exécute aussi la pièce « redeploy traefik » sur `localhost`, qui **supprime le Deployment `traefik` et le Job `helm-install-traefik` dans le contexte kubectl COURANT**, et celui-ci n'est pas forcément le homelab. Le commentaire ajouté le dit.
## Vérifications faites avant
- **Rendu Helm** : `helm template longhorn-1.9.1.tgz` avant/après ne diffère que d'une ligne, `engine-replica-timeout: 20` dans la ConfigMap `longhorn-default-setting`. Aucune annotation de somme de contrôle : aucun pod n'est recréé.
- **Release en place** : `helm get manifest longhorn-install` est identique au rendu « avant », hors hooks. La mise à niveau n'emporte donc aucune dérive cachée.
- **Manifeste réellement posé sur pi1** : identique au dépôt.
- **`--list-tasks --tags longhorn`** : seule la tâche Longhorn, plus l'`add_host` en `always`. La pièce traefik n'a aucune tâche sélectionnée.
- **`--check --diff`** : un seul changement, les lignes ci-dessus dans `/var/lib/rancher/k3s/server/manifests/longhorn-install.yaml`.
## Application
```
ansible-playbook -i ansible/arcodange/factory/inventory ansible/arcodange/factory/playbooks/system/k3s_config.yml --tags longhorn
```
Ensuite : le helm-controller de k3s rejoue la release (révision 2, hooks `pre-upgrade`/`post-upgrade` de Longhorn), puis on relit `settings.longhorn.io/engine-replica-timeout`.
Aucune CI ne couvre `ansible/`.
Refs arcodange-org/tools#52
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Le 14/09, le moteur Longhorn de pi2 (saturé en mémoire) a manqué le délai
de 8 s ; les écritures sont revenues au noyau en `critical medium error`
et ext4 a abandonné son journal sur quatre volumes (tools#49).
`defaultSettings.engineReplicaTimeout: 20` dans le HelmChart posé par
k3s_config.yml. Le dernier réplica est déclaré mort au double (40 s), sous
le délai SCSI des disques Longhorn (60 s). Rendu `helm template` v1.9.1
avant/après : seule la ConfigMap `longhorn-default-setting` change.
La tâche reçoit le tag `longhorn` pour être rejouée seule : sans tag, le
playbook supprime aussi le Deployment traefik dans le contexte kubectl
courant.
Refs arcodange-org/tools#52
Co-Authored-By: Claude Opus 5 <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Pourquoi (arcodange-org/tools#49, #52)
Le 14/09, le moteur Longhorn de pi2, saturé en mémoire, a journalisé
R/W Timeout. No response received in 8s. Les écritures sont ensuite revenues au noyau encritical medium error(cmd_age=23s), et ext4 a abandonné son journal sur quatre volumes : MinIO, loki, url-shortener et prometheus-server.La mémoire de pi2 est soulagée depuis ce matin (factory#58 : 2,6 Gi rendus). Ce réglage retire le mécanisme lui-même, pas seulement le terrain.
Accord du fondateur : « Oui, après avoir soulagé pi2 ».
Le réglage
engine-replica-timeout(Helm :defaultSettings.engineReplicaTimeout), 8 → 20 s.Doc Longhorn v1.9.1, Settings Reference :
Pourquoi 20 et pas 30 : le dernier réplica n'est déclaré mort qu'au double. Le délai SCSI du noyau sur les disques Longhorn vaut 60 s (relevé sur les 3 Pi :
/sys/dev/block/<maj:min>/device/timeout). Avec 30, on atteindrait 60 s, soit le délai du noyau lui-même : c'est le noyau qui abandonnerait la commande et renverrait l'erreur. Avec 20, on reste à 40 s, sous les 60.Le prix
--engine-replica-timeout 8, relevé danspssur pi3). Les volumes déjà attachés gardent 8 s jusqu'à leur prochain rattachement. Aucun rattachement n'est forcé par cette PR.Ce qui change
playbooks/system/k3s_config.yml: la valeur est ajoutée auvaluesContentdu HelmChartlonghorn-install.longhornpour être rejouée seule.localhost, qui supprime le Deploymenttraefiket le Jobhelm-install-traefikdans le contexte kubectl COURANT, et celui-ci n'est pas forcément le homelab. Le commentaire ajouté le dit.Vérifications faites avant
helm template longhorn-1.9.1.tgzavant/après ne diffère que d'une ligne,engine-replica-timeout: 20dans la ConfigMaplonghorn-default-setting. Aucune annotation de somme de contrôle : aucun pod n'est recréé.helm get manifest longhorn-installest identique au rendu « avant », hors hooks. La mise à niveau n'emporte donc aucune dérive cachée.--list-tasks --tags longhorn: seule la tâche Longhorn, plus l'add_hostenalways. La pièce traefik n'a aucune tâche sélectionnée.--check --diff: un seul changement, les lignes ci-dessus dans/var/lib/rancher/k3s/server/manifests/longhorn-install.yaml.Application
Ensuite : le helm-controller de k3s rejoue la release (révision 2, hooks
pre-upgrade/post-upgradede Longhorn), puis on relitsettings.longhorn.io/engine-replica-timeout.Aucune CI ne couvre
ansible/.Refs arcodange-org/tools#52
🤖 Generated with Claude Code