Ruediger Meier <sweet_f_a@xxxxxx> 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@xxxxxxxx>
> > ---
> > 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.
Anyway... Feel free to deny committing the patch. For now I added a
configuration snipped on my system.
--
Schoene Gruesse
Chris
Attachment:
pgpkmEeTnHieC.pgp
Description: OpenPGP digital signature
