From 61ab74c70eca4ddc3ad107eae6dd217d075c990e Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 9 Oct 2026 01:54:51 +0200 Subject: [PATCH] ADR 0269: the catch-up happens when the timer's last run is more than a week back --- ...-own-declaration-stopped-is-started-again-when-it-goes.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/02-DECISIONS/0269-what-the-meshs-own-declaration-stopped-is-started-again-when-it-goes.md b/02-DECISIONS/0269-what-the-meshs-own-declaration-stopped-is-started-again-when-it-goes.md index 4101019d..9de5b485 100644 --- a/02-DECISIONS/0269-what-the-meshs-own-declaration-stopped-is-started-again-when-it-goes.md +++ b/02-DECISIONS/0269-what-the-meshs-own-declaration-stopped-is-started-again-when-it-goes.md @@ -82,8 +82,9 @@ before the mesh came, and the mesh's stopping it was the mesh's doing, which goe - **A restored timer catches up at once.** A timer with `Persistent=true` that was stopped past its scheduled time fires as soon as it is started again. On the home server the distribution's weekly scrub timer is such a timer, and a scrub of its pool took about 46 hours (2026-10-05 00:08 to 2026-10-06 - 22:06). Unassigning the `zfs` module therefore starts a scrub of about 46 hours, within the hour of - the timer's random delay. Unassign it when that load is acceptable. + 22:06). Unassigning the `zfs` module after the timer's last run is more than a week back therefore + starts a scrub of about 46 hours, within the hour of the timer's random delay. Unassign it when that + load is acceptable. - **Harder:** a unit the mesh stopped and that should *stay* stopped after the module goes (one that was found running by accident) is now started again. Saying so needs a field on the resource, which no module needs yet. Until one does, the plan's `restore … started … again` step is where it is seen.