From: Ruediger Meier <sweet_f_a@gmx.de>
To: Christian Hesse <mail@eworm.de>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH 1/1] fstrim: add random delay to systemd timer
Date: Mon, 17 Dec 2018 23:13:35 +0100 [thread overview]
Message-ID: <201812172313.35898.sweet_f_a@gmx.de> (raw)
In-Reply-To: <20181217221518.5a68691f@leda>
On Monday 17 December 2018, Christian Hesse wrote:
> Ruediger Meier <sweet_f_a@gmx.de> on Mon, 2018/12/17 21:45:
> > On Monday 17 December 2018, Christian Hesse wrote:
> > > The fstrim timer tends to fire simultaneously with other timers
> > > like updatedb. As fstrim is not time criticaly let's add a random
> > > delay of up to an hour.
> > >
> > > Signed-off-by: Christian Hesse <mail@eworm.de>
> > > ---
> > > sys-utils/fstrim.timer | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/sys-utils/fstrim.timer b/sys-utils/fstrim.timer
> > > index 3a3762d5c..dd3328e2a 100644
> > > --- a/sys-utils/fstrim.timer
> > > +++ b/sys-utils/fstrim.timer
> > > @@ -5,6 +5,7 @@ Documentation=man:fstrim
> > > [Timer]
> > > OnCalendar=weekly
> > > AccuracySec=1h
> > > +RandomizedDelaySec=1h
> >
> > Looks like it could still run simultaneously with other timers at
> > random times. So this does not seem to be a real fix for the
> > problem described in your commit message.
> >
> > You may look at /etc/cron.{hourly,daily,weekly,monthly} if you want
> > to run such jobs one after the other.
>
> There's no harm when jobs run simultaneously, other than bad user
> experience: Consider a user stating his notebook, workstation,
> whatever on a Monday morning and system feels bad under high load.
> This can be avoided (most of the time) with just a single line in the
> timer. I think it is worth it.
Hm, on my file server updatedb needs about 30 minutes. A random delay of
1 hour means that both jobs will still run simultaneously in 50% of the
cases.
> Anyway... Feel free to deny committing the patch. For now I added a
> configuration snipped on my system.
Nevermind, I just wanted to rant again about why we are maintaining this
timer files at all. IMO the distros and/or admins should configure such
tasks *properly* according their needs. UL upstream is IMHO the wrong
place.
BTW note that RandomizedDelaySec will produce an annoying warning on
sytstems where systemd is not up-to date. And to rant again, IMO it's
questionable whether we should bother users with such warnings or why
one should update the whole systemd monstrum just to achieve such
simple improvement which was solved already by cron 30 years ago in a
better way ;)
cu,
Rudi
next prev parent reply other threads:[~2018-12-17 22:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-17 12:44 [PATCH 1/1] fstrim: add random delay to systemd timer Christian Hesse
2018-12-17 20:45 ` Ruediger Meier
2018-12-17 21:15 ` Christian Hesse
2018-12-17 22:13 ` Ruediger Meier [this message]
2018-12-18 9:45 ` Karel Zak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201812172313.35898.sweet_f_a@gmx.de \
--to=sweet_f_a@gmx.de \
--cc=mail@eworm.de \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox