Util-Linux Archive on lore.kernel.org
 help / Atom feed
* [PATCH 1/1] fstrim: add random delay to systemd timer
@ 2018-12-17 12:44 Christian Hesse
  2018-12-17 20:45 ` Ruediger Meier
  0 siblings, 1 reply; 5+ messages in thread
From: Christian Hesse @ 2018-12-17 12:44 UTC (permalink / raw)
  To: util-linux; +Cc: Christian Hesse

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
 Persistent=true
 
 [Install]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1] fstrim: add random delay to systemd timer
  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
  0 siblings, 1 reply; 5+ messages in thread
From: Ruediger Meier @ 2018-12-17 20:45 UTC (permalink / raw)
  To: Christian Hesse; +Cc: util-linux

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.

cu,
Rudi

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1] fstrim: add random delay to systemd timer
  2018-12-17 20:45 ` Ruediger Meier
@ 2018-12-17 21:15   ` Christian Hesse
  2018-12-17 22:13     ` Ruediger Meier
  0 siblings, 1 reply; 5+ messages in thread
From: Christian Hesse @ 2018-12-17 21:15 UTC (permalink / raw)
  To: Ruediger Meier; +Cc: util-linux

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

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.

Anyway... Feel free to deny committing the patch. For now I added a
configuration snipped on my system.
-- 
Schoene Gruesse
Chris

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1] fstrim: add random delay to systemd timer
  2018-12-17 21:15   ` Christian Hesse
@ 2018-12-17 22:13     ` Ruediger Meier
  2018-12-18  9:45       ` Karel Zak
  0 siblings, 1 reply; 5+ messages in thread
From: Ruediger Meier @ 2018-12-17 22:13 UTC (permalink / raw)
  To: Christian Hesse; +Cc: util-linux

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/1] fstrim: add random delay to systemd timer
  2018-12-17 22:13     ` Ruediger Meier
@ 2018-12-18  9:45       ` Karel Zak
  0 siblings, 0 replies; 5+ messages in thread
From: Karel Zak @ 2018-12-18  9:45 UTC (permalink / raw)
  To: Ruediger Meier; +Cc: Christian Hesse, util-linux

On Mon, Dec 17, 2018 at 11:13:35PM +0100, Ruediger Meier wrote:
> 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.

Well, distro still can improve upstream configuration, the files is
just the default hint. It's better to share this code than force all
distro duplicate effort. Perfect is enemy of good :-) The files are
installed (by make install), but not enabled by default -- the
activation is distro/user decision.

And according to feedback it seems people use the fstrim.timer, so why
not share it and work together on better fstrim and timer
configuration?

> 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 ;)

Well, I'm not systemd expert, but I guess you can define dependences
between services to avoid unwanted collisions between services.

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2018-12-18  9:45       ` Karel Zak

Util-Linux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/util-linux/0 util-linux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 util-linux util-linux/ https://lore.kernel.org/util-linux \
		util-linux@vger.kernel.org util-linux@archiver.kernel.org
	public-inbox-index util-linux


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.util-linux


AGPL code for this site: git clone https://public-inbox.org/ public-inbox