[PATCH] fstrim: add systemd units

[PATCH] fstrim: add systemd units

[Thomas Bächler]

This adds a timer and a service for systemd that runs
fstrim -a once a day.

The Persistent=true option used will only work on systemd 212
or newer.
---
 sys-utils/.gitignore        |  1 +
 sys-utils/Makemodule.am     |  6 ++++++
 sys-utils/fstrim.service.in |  6 ++++++
 sys-utils/fstrim.timer      | 10 ++++++++++
 4 files changed, 23 insertions(+)
 create mode 100644 sys-utils/fstrim.service.in
 create mode 100644 sys-utils/fstrim.timer

diff --git a/sys-utils/.gitignore b/sys-utils/.gitignore
index 8d8737a..bcd6e02 100644
--- a/sys-utils/.gitignore
+++ b/sys-utils/.gitignore
@@ -18,3 +18,4 @@ sparc32.8
 sparc32bash.8
 sparc64.8
 x86_64.8
+fstrim.service
diff --git a/sys-utils/Makemodule.am b/sys-utils/Makemodule.am
index ae254a3..1c2b210 100644
--- a/sys-utils/Makemodule.am
+++ b/sys-utils/Makemodule.am
@@ -53,8 +53,14 @@ dist_man_MANS += sys-utils/fstrim.8
 fstrim_SOURCES = sys-utils/fstrim.c
 fstrim_LDADD = $(LDADD) libcommon.la libmount.la
 fstrim_CFLAGS = $(AM_CFLAGS) -I$(ul_libmount_incdir)
+systemdsystemunit_DATA += \
+	sys-utils/fstrim.service \
+	sys-utils/fstrim.timer
 endif
 
+PATHFILES += \
+	sys-utils/fstrim.service
+
 if LINUX
 #
 # Linux-only utils with no another dependencies. All another dependencies have
diff --git a/sys-utils/fstrim.service.in b/sys-utils/fstrim.service.in
new file mode 100644
index 0000000..52155d0
--- /dev/null
+++ b/sys-utils/fstrim.service.in
@@ -0,0 +1,6 @@
+[Unit]
+Description=Discard unused blocks
+
+[Service]
+Type=oneshot
+ExecStart=@sbindir@/fstrim -a
diff --git a/sys-utils/fstrim.timer b/sys-utils/fstrim.timer
new file mode 100644
index 0000000..24eeee5
--- /dev/null
+++ b/sys-utils/fstrim.timer
@@ -0,0 +1,10 @@
+[Unit]
+Description=Discard unused blocks once a day
+
+[Timer]
+OnCalendar=daily
+AccuracySec=1h
+Persistent=true
+
+[Install]
+WantedBy=multi-user.target
-- 
1.9.1

Re: [PATCH] fstrim: add systemd units

[Karel Zak]

On Thu, Apr 03, 2014 at 11:41:51PM +0200, Thomas Bächler wrote:
>  sys-utils/.gitignore        |  1 +
>  sys-utils/Makemodule.am     |  6 ++++++
>  sys-utils/fstrim.service.in |  6 ++++++
>  sys-utils/fstrim.timer      | 10 ++++++++++
>  4 files changed, 23 insertions(+)
>  create mode 100644 sys-utils/fstrim.service.in
>  create mode 100644 sys-utils/fstrim.timer

 Applied, thanks.

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

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Monday 07 April 2014, Karel Zak wrote:
> On Thu, Apr 03, 2014 at 11:41:51PM +0200, Thomas Bächler wrote:
> >  sys-utils/.gitignore        |  1 +
> >  sys-utils/Makemodule.am     |  6 ++++++
> >  sys-utils/fstrim.service.in |  6 ++++++
> >  sys-utils/fstrim.timer      | 10 ++++++++++
> >  4 files changed, 23 insertions(+)
> >  create mode 100644 sys-utils/fstrim.service.in
> >  create mode 100644 sys-utils/fstrim.timer
>
>  Applied, thanks.

Hm, isn't this a bit over the top? Adding a script just to 
call "fstrim -a" automatically?
Should we also add scripts for "mount -a" or "fsck -a" or "swapon -a"?

And wouldn't we also need to add "example crontab" lines for non-systemd 
systems! Sounds a bit ridiculous, right?

I think it's the distro's or admin's job to write and add the scripts 
for filesystems maintenance etc.

BTW fstrim.timer is missing in "make dist" tar ball.

cu,
Rudi

Re: [PATCH] fstrim: add systemd units

[Thomas Bächler]

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

Am 08.04.2014 12:25, schrieb Ruediger Meier:
> Hm, isn't this a bit over the top? Adding a script just to 
> call "fstrim -a" automatically?

It's a common task. I was getting tired of having to add this on every
single machine that I set up.

> Should we also add scripts for "mount -a" or "fsck -a" or "swapon -a"?

And what purpose would that serve? Did you just take random commands and
add '-a' to prove a point?

> And wouldn't we also need to add "example crontab" lines for non-systemd 
> systems! Sounds a bit ridiculous, right?

You can add them if you feel like it. But this is not an "example" file,
it is ready to be used.

> I think it's the distro's or admin's job to write and add the scripts 
> for filesystems maintenance etc.

That's ridiculous. We finally, for the first time ever, have a unified
way of creating service definitions that can be used unchanged in all
relevant distributions (except Gentoo and Slackware, of course). The
main advantage of this unification is that they can be shipped and
maintained by upstream projects - after all, the upstream projects know
what services make sense and how to start them properly.

> BTW fstrim.timer is missing in "make dist" tar ball.

Sorry, you are right. I'm a bit lost in this build system, Karel
probably knows how to fix this.



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

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Tuesday 08 April 2014, Thomas B=C3=A4chler wrote:
> Am 08.04.2014 12:25, schrieb Ruediger Meier:
> > Hm, isn't this a bit over the top? Adding a script just to
> > call "fstrim -a" automatically?
>
> It's a common task. I was getting tired of having to add this on
> every single machine that I set up.

=46or me it's very common task to do "rm -rf /tmp" after each reboot. I=20
have to setup this on every single machine. Should I go to coreutils,=20
the developers of rm to add a script which calls "rm -rf /tmp" on=20
reboot?
No, of course my distribution should give me that feature.

> > Should we also add scripts for "mount -a" or "fsck -a" or "swapon
> > -a"?
>
> And what purpose would that serve? Did you just take random commands
> and add '-a' to prove a point?

I wanted to point out that util-linux is a project to provide us tools=20
and not all the ways how and when to use them. systemd ustream is=20
mounting and fsck'ing our filesystems automatically. So they can also=20
fstrim if they find it useful.

> > And wouldn't we also need to add "example crontab" lines for
> > non-systemd systems! Sounds a bit ridiculous, right?
>
> You can add them if you feel like it. But this is not an "example"
> file, it is ready to be used.

An example crontab line is also ready to use. Your example timer is=20
(hopefully) not automatically enabled just because it is installed.

> > I think it's the distro's or admin's job to write and add the
> > scripts for filesystems maintenance etc.
>
> That's ridiculous. We finally, for the first time ever, have a
> unified way of creating service definitions that can be used
> unchanged in all relevant distributions (except Gentoo and Slackware,
> of course).

Beside the fact that before "unique service definitions" were invented=20
nobody would have thought that one would need such thing just to call a=20
single commandline one time per day.

> The main advantage of this unification is that they can =20
> be shipped and maintained by upstream projects - after all, the
> upstream projects know what services make sense and how to start them
> properly.

I don't say something against systemd here and I don't see this black=20
and white only. I'am just against adding sysadmin scripts which=20
actually do only trivial things. Though it might be worth to add such=20
unit file if it does something more interesting, like we have already=20
uuidd.service and uuidd.socket (and uuidd.rc) which provides nices ways=20
how to start uuidd.

> > BTW fstrim.timer is missing in "make dist" tar ball.
>
> Sorry, you are right. I'm a bit lost in this build system, Karel
> probably knows how to fix this.

cu,
Rudi

Re: [PATCH] fstrim: add systemd units

[Dave Reisner]

On Tue, Apr 08, 2014 at 02:07:28PM +0200, Ruediger Meier wrote:
> On Tuesday 08 April 2014, Thomas Bächler wrote:
> > Am 08.04.2014 12:25, schrieb Ruediger Meier:
> > > Hm, isn't this a bit over the top? Adding a script just to
> > > call "fstrim -a" automatically?
> >
> > It's a common task. I was getting tired of having to add this on
> > every single machine that I set up.
> 
> For me it's very common task to do "rm -rf /tmp" after each reboot. I 
> have to setup this on every single machine. Should I go to coreutils, 
> the developers of rm to add a script which calls "rm -rf /tmp" on 
> reboot?
> No, of course my distribution should give me that feature.

You're again comparing one-time bootstrap tasks to recurring maintenance
tasks. Does your distribution ship any cronjobs which reside in
/etc/cron.*? You'd be better off comparing the proposed timer and
service unit to this.

> > > Should we also add scripts for "mount -a" or "fsck -a" or "swapon
> > > -a"?
> >
> > And what purpose would that serve? Did you just take random commands
> > and add '-a' to prove a point?
> 
> I wanted to point out that util-linux is a project to provide us tools 
> and not all the ways how and when to use them. systemd ustream is 
> mounting and fsck'ing our filesystems automatically. So they can also 
> fstrim if they find it useful.

Again, you're not making a reasonable comparison here.

> > > And wouldn't we also need to add "example crontab" lines for
> > > non-systemd systems! Sounds a bit ridiculous, right?
> >
> > You can add them if you feel like it. But this is not an "example"
> > file, it is ready to be used.
> 
> An example crontab line is also ready to use. Your example timer is 
> (hopefully) not automatically enabled just because it is installed.

No, it's up to the local admin to enable it.

> > > I think it's the distro's or admin's job to write and add the
> > > scripts for filesystems maintenance etc.
> >
> > That's ridiculous. We finally, for the first time ever, have a
> > unified way of creating service definitions that can be used
> > unchanged in all relevant distributions (except Gentoo and Slackware,
> > of course).
> 
> Beside the fact that before "unique service definitions" were invented 
> nobody would have thought that one would need such thing just to call a 
> single commandline one time per day.

Really? You've never heard of cron?

> > The main advantage of this unification is that they can  
> > be shipped and maintained by upstream projects - after all, the
> > upstream projects know what services make sense and how to start them
> > properly.
> 
> I don't say something against systemd here and I don't see this black 
> and white only. I'am just against adding sysadmin scripts which 
> actually do only trivial things. Though it might be worth to add such 
> unit file if it does something more interesting, like we have already 
> uuidd.service and uuidd.socket (and uuidd.rc) which provides nices ways 
> how to start uuidd.

> > > BTW fstrim.timer is missing in "make dist" tar ball.
> >
> > Sorry, you are right. I'm a bit lost in this build system, Karel
> > probably knows how to fix this.
> 
> cu,
> Rudi
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Tuesday 08 April 2014, Dave Reisner wrote:
> On Tue, Apr 08, 2014 at 02:07:28PM +0200, Ruediger Meier wrote:
> > On Tuesday 08 April 2014, Thomas Bchler wrote:
> > > Am 08.04.2014 12:25, schrieb Ruediger Meier:
> > > > Hm, isn't this a bit over the top? Adding a script just to
> > > > call "fstrim -a" automatically?
> > >
> > > It's a common task. I was getting tired of having to add this on
> > > every single machine that I set up.
> >
> > For me it's very common task to do "rm -rf /tmp" after each reboot.
> > I have to setup this on every single machine. Should I go to
> > coreutils, the developers of rm to add a script which calls "rm -rf
> > /tmp" on reboot?
> > No, of course my distribution should give me that feature.
>
> You're again comparing one-time bootstrap tasks to recurring
> maintenance tasks. Does your distribution ship any cronjobs which
> reside in /etc/cron.*?

Of course they do ... /etc/cron.daily/suse.de-clean-tmp ... to "find" 
some files and "rm" them. This script comes with the distro and neither 
from coreutils (rm) nor findutils (find).

> You'd be better off comparing the proposed 
> timer and service unit to this.

?

> > > > Should we also add scripts for "mount -a" or "fsck -a" or
> > > > "swapon -a"?
> > >
> > > And what purpose would that serve? Did you just take random
> > > commands and add '-a' to prove a point?
> >
> > I wanted to point out that util-linux is a project to provide us
> > tools and not all the ways how and when to use them. systemd
> > ustream is mounting and fsck'ing our filesystems automatically. So
> > they can also fstrim if they find it useful.
>
> Again, you're not making a reasonable comparison here.
>
> > > > And wouldn't we also need to add "example crontab" lines for
> > > > non-systemd systems! Sounds a bit ridiculous, right?
> > >
> > > You can add them if you feel like it. But this is not an
> > > "example" file, it is ready to be used.
> >
> > An example crontab line is also ready to use. Your example timer is
> > (hopefully) not automatically enabled just because it is installed.
>
> No, it's up to the local admin to enable it.
>
> > > > I think it's the distro's or admin's job to write and add the
> > > > scripts for filesystems maintenance etc.
> > >
> > > That's ridiculous. We finally, for the first time ever, have a
> > > unified way of creating service definitions that can be used
> > > unchanged in all relevant distributions (except Gentoo and
> > > Slackware, of course).
> >
> > Beside the fact that before "unique service definitions" were
> > invented nobody would have thought that one would need such thing
> > just to call a single commandline one time per day.
>
> Really? You've never heard of cron?

You haven't understood my poor english I guess. I ment everybody knows 
since 40 years how to do such trivial task by using cron. Now since we 
have that great systemd's timer service definitions we start to add 2 
new files for such simple task to a core project like util-linux ...? 
That's what I ment with "a bit over the top" in my first email.

I know nobody will die if util-linux ships such fstrim.timer but it's 
IMO ugly and the wrong place.

> > > The main advantage of this unification is that they can
> > > be shipped and maintained by upstream projects - after all, the
> > > upstream projects know what services make sense and how to start
> > > them properly.
> >
> > I don't say something against systemd here and I don't see this
> > black and white only. I'am just against adding sysadmin scripts
> > which actually do only trivial things. Though it might be worth to
> > add such unit file if it does something more interesting, like we
> > have already uuidd.service and uuidd.socket (and uuidd.rc) which
> > provides nices ways how to start uuidd.
> >
> > > > BTW fstrim.timer is missing in "make dist" tar ball.
> > >
> > > Sorry, you are right. I'm a bit lost in this build system, Karel
> > > probably knows how to fix this.

cu,
Rudi

Re: [PATCH] fstrim: add systemd units

[Karel Zak]

On Tue, Apr 08, 2014 at 02:07:28PM +0200, Ruediger Meier wrote:
> I don't say something against systemd here and I don't see this black 
> and white only. I'am just against adding sysadmin scripts which 
> actually do only trivial things. 

Well, it's not so important if the file is trivial or non-trivial --
the overhead for distributions is usually almost the same. It's always
cheaper to maintain distribution independent stuff on one shared place.

    Karel

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

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Wednesday 09 April 2014, Karel Zak wrote:
> On Tue, Apr 08, 2014 at 02:07:28PM +0200, Ruediger Meier wrote:
> > I don't say something against systemd here and I don't see this
> > black and white only. I'am just against adding sysadmin scripts
> > which actually do only trivial things.
>
> Well, it's not so important if the file is trivial or non-trivial --
> the overhead for distributions is usually almost the same. It's
> always cheaper to maintain distribution independent stuff on one
> shared place.

I understand, but isn't the usefulness of a daily job "fstrim -a" 
debatable at all? Should this be discussed by core util-linux 
developers or not better by sysadmins and distribution developers?
Actually I think daily "fstrim -a" IS not a good idea for most of my 
systems but I feel no need to discuss this here on util-linux because 
the decision whether, how, when and on which devices fstrim should be 
called should not be made here at all.

And I find my other examples in this thread not so stupid.
If we add scripts with one generic use case for fstrim. Why don't we add 
the generic boot and maintenance scripts how and when to mount or fsck 
all filesystems, to activate swap, to get and set hwclock or whatever?

Moreover the portability issue. Why adding scripts for systemd only 
allthough the same could be done without systemd in a more portable 
way.

cu,
Rudi

Re: [PATCH] fstrim: add systemd units

[Karel Zak]

On Wed, Apr 09, 2014 at 12:07:56PM +0200, Ruediger Meier wrote:
> Actually I think daily "fstrim -a" IS not a good idea for most of my 
> systems

install service != enable (this is important detail, I'll never agree
with automatically enabled services).

BTW, why IS not a good idea for your systems?

> but I feel no need to discuss this here on util-linux because 
> the decision whether, how, when and on which devices fstrim should be 
> called should not be made here at all.

well, "fstrim -a" contains heruistic to select the right filestems (it
really does not call trim for all devices), it has been implemented to
*avoid* sysadmins creativity. If you don't like it, you can use
"fstrim <device>" (for example from crontab).

> If we add scripts with one generic use case for fstrim. Why don't we add 
> the generic boot and maintenance scripts how and when to mount or fsck 
> all filesystems, to activate swap, to get and set hwclock or whatever?

I really don't want to follow this insane direction of the discussion.

> Moreover the portability issue. Why adding scripts for systemd only 
> allthough the same could be done without systemd in a more portable 
> way.

is there any other unified, distribution independent and distribution
supported way to install, but no enable the stuff?

    Karel

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

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Wednesday 09 April 2014, Karel Zak wrote:
> On Wed, Apr 09, 2014 at 12:07:56PM +0200, Ruediger Meier wrote:
> > Actually I think daily "fstrim -a" IS not a good idea for most of
> > my systems
>
> install service != enable (this is important detail, I'll never agree
> with automatically enabled services).

> BTW, why IS not a good idea for your systems?

Because I don't need it. 

> > but I feel no need to discuss this here on util-linux because
> > the decision whether, how, when and on which devices fstrim should
> > be called should not be made here at all.
>
> well, "fstrim -a" contains heruistic to select the right filestems
> (it really does not call trim for all devices), it has been
> implemented to *avoid* sysadmins creativity. If you don't like it,
> you can use "fstrim <device>" (for example from crontab).

I'd like the documentation more detailed.
Does it really run on all mounts or only /etc/fstab?
Does it write on automounted devices which are probably not owned by the 
admin? Does it affect read-only mounts?

> > If we add scripts with one generic use case for fstrim. Why don't
> > we add the generic boot and maintenance scripts how and when to
> > mount or fsck all filesystems, to activate swap, to get and set
> > hwclock or whatever?
>
> I really don't want to follow this insane direction of the
> discussion.
>
> > Moreover the portability issue. Why adding scripts for systemd only
> > allthough the same could be done without systemd in a more portable
> > way.
>
> is there any other unified, distribution independent and distribution
> supported way to install, but no enable the stuff?

This fstrim.timer IS NOT unified and distribution independent.

IMO the task itself is already installed since we have fstrim's 
option -a". You just need to _enable_ it to run whenever you want for 
example by using crontab. That's trivial.

Nobody would have thought about adding a 1-liner cronjob file to 
util-linux eventhough any distro has /etc/cron.daily/. But now systemd 
timer? Thats what I don't understand.

Ah ... and the "not-enabled" cronjob could have been installed somewhere 
in /usr/share/ or /etc/sysconfig to be linked from /etc/cron.daily/. 
And ... this cronjob would be even more comfortable because you could 
link it from  cron.daily/ cron.hourly/ cron.monthly/ cron.weekly/
without need to copy and edit like such systemd.timer.

If _creating_ a systemd timer is too complicated for today's admins then 
systemd upstream could add a command like
  systemd-create-timer --daily --exec "fstrim -a"
to create and enable it.

cu,
Rudi

Re: [PATCH] fstrim: add systemd units

[Thomas Bächler]

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

Am 09.04.2014 14:12, schrieb Ruediger Meier:
>> well, "fstrim -a" contains heruistic to select the right filestems
>> (it really does not call trim for all devices), it has been
>> implemented to *avoid* sysadmins creativity. If you don't like it,
>> you can use "fstrim <device>" (for example from crontab).
> 
> I'd like the documentation more detailed.
> Does it really run on all mounts or only /etc/fstab?
> Does it write on automounted devices which are probably not owned by the 
> admin? Does it affect read-only mounts?

The documentation is precise here:

'Trim all mounted filesystems on devices that support the discard
operation.'

It says exactly what it will do. Every one of your questions is answered.

> IMO the task itself is already installed since we have fstrim's 
> option -a". You just need to _enable_ it to run whenever you want for 
> example by using crontab. That's trivial.

Because it takes time. I have done it four times already and it cost me
several minutes each time. Now nobody has to do it again.

> Nobody would have thought about adding a 1-liner cronjob file to 
> util-linux eventhough any distro has /etc/cron.daily/. But now systemd 
> timer? Thats what I don't understand.

I don't know why nobody thought about doing that in the past, maybe
nobody cared about the needs of all those other admins. Maybe because
installing a file into cron.daily automatically enables it. Maybe
because nobody cared about anything but his own system?

> If _creating_ a systemd timer is too complicated for today's admins

It is not complicated, it is just a task that shouldn't be repeated
countless times.



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

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Wednesday 09 April 2014, Thomas Bächler wrote:
> Am 09.04.2014 14:12, schrieb Ruediger Meier:
> >> well, "fstrim -a" contains heruistic to select the right filestems
> >> (it really does not call trim for all devices), it has been
> >> implemented to *avoid* sysadmins creativity. If you don't like it,
> >> you can use "fstrim <device>" (for example from crontab).
> >
> > I'd like the documentation more detailed.
> > Does it really run on all mounts or only /etc/fstab?
> > Does it write on automounted devices which are probably not owned
> > by the admin? Does it affect read-only mounts?
>
> The documentation is precise here:
>
> 'Trim all mounted filesystems on devices that support the discard
> operation.'

If this is 100% true then Karel's statement 10 lines above would be 
wrong.
Also this doc line indicates that even read-only mounts could be trimmed 
(if FS supports it) which would be at least dangerous if it runs 
automatically while admin is trying to repair a broken filesystem.

> It says exactly what it will do. Every one of your questions is
> answered.

> > IMO the task itself is already installed since we have fstrim's
> > option -a". You just need to _enable_ it to run whenever you want
> > for example by using crontab. That's trivial.
>
> Because it takes time. I have done it four times already and it cost
> me several minutes each time. Now nobody has to do it again.

> > Nobody would have thought about adding a 1-liner cronjob file to
> > util-linux eventhough any distro has /etc/cron.daily/. But now
> > systemd timer? Thats what I don't understand.
>
> I don't know why nobody thought about doing that in the past, maybe
> nobody cared about the needs of all those other admins. Maybe because
> installing a file into cron.daily automatically enables it. Maybe
> because nobody cared about anything but his own system?

I guess because adding one crontab line is trivial in comparision to add 
two files plus symlinks to get such systemd timer running. 

> > If _creating_ a systemd timer is too complicated for today's admins
>
> It is not complicated, it is just a task that shouldn't be repeated
> countless times.

Now you still need to enable it "countless times" which I would do using 
rsync or git anyway like I would sync self created timers, crontabs or 
whatever config files with same effort.

cu,
Rudi

Re: [PATCH] fstrim: add systemd units

[Thomas Bächler]

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

Am 09.04.2014 17:16, schrieb Ruediger Meier:
> On Wednesday 09 April 2014, Thomas Bächler wrote:
>> Am 09.04.2014 14:12, schrieb Ruediger Meier:
>>>> well, "fstrim -a" contains heruistic to select the right filestems
>>>> (it really does not call trim for all devices), it has been
>>>> implemented to *avoid* sysadmins creativity. If you don't like it,
>>>> you can use "fstrim <device>" (for example from crontab).
>>>
>>> I'd like the documentation more detailed.
>>> Does it really run on all mounts or only /etc/fstab?
>>> Does it write on automounted devices which are probably not owned
>>> by the admin? Does it affect read-only mounts?
>>
>> The documentation is precise here:
>>
>> 'Trim all mounted filesystems on devices that support the discard
>> operation.'
> 
> If this is 100% true then Karel's statement 10 lines above would be 
> wrong.

There is no contradiction between this and what Karel said. I think you
are confused and should read both statements again.

> Also this doc line indicates that even read-only mounts could be trimmed 
> (if FS supports it) which would be at least dangerous if it runs 
> automatically while admin is trying to repair a broken filesystem.

The documentation says nothing about excluding read-only file systems,
that should probably be changed (but it is not something that I,
personally, am terribly concerned about).

>> It is not complicated, it is just a task that shouldn't be repeated
>> countless times.
> 
> Now you still need to enable it "countless times" which I would do using 
> rsync or git anyway like I would sync self created timers, crontabs or 
> whatever config files with same effort.

This is getting annoying. It is your opinion that we should not add
useful things because we haven't done so in the past, or because someone
might want to do it slightly differently.

I submitted it, Karel added it, period. There's no point continuing this
argument.



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

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Wednesday 09 April 2014, Thomas B=C3=A4chler wrote:
> Am 09.04.2014 17:16, schrieb Ruediger Meier:
> > On Wednesday 09 April 2014, Thomas B=C3=A4chler wrote:
> >> Am 09.04.2014 14:12, schrieb Ruediger Meier:
> >>>> well, "fstrim -a" contains heruistic to select the right
> >>>> filestems (it really does not call trim for all devices), it has
> >>>> been implemented to *avoid* sysadmins creativity. If you don't
> >>>> like it, you can use "fstrim <device>" (for example from
> >>>> crontab).
> >>>
> >>> I'd like the documentation more detailed.
> >>> Does it really run on all mounts or only /etc/fstab?
> >>> Does it write on automounted devices which are probably not owned
> >>> by the admin? Does it affect read-only mounts?
> >>
> >> The documentation is precise here:
> >>
> >> 'Trim all mounted filesystems on devices that support the discard
> >> operation.'
> >
> > If this is 100% true then Karel's statement 10 lines above would be
> > wrong.
>
> There is no contradiction between this and what Karel said. I think
> you are confused and should read both statements again.

Yes I am confused now and read again.
Karel wrote "fstrim -a contains heruistic to select the right
filestems" which is something completely different than doing it=20
wherever it's possible.

> > Also this doc line indicates that even read-only mounts could be
> > trimmed (if FS supports it) which would be at least dangerous if it
> > runs automatically while admin is trying to repair a broken
> > filesystem.
>
> The documentation says nothing about excluding read-only file
> systems, that should probably be changed (but it is not something
> that I, personally, am terribly concerned about).
>
> >> It is not complicated, it is just a task that shouldn't be
> >> repeated countless times.
> >
> > Now you still need to enable it "countless times" which I would do
> > using rsync or git anyway like I would sync self created timers,
> > crontabs or whatever config files with same effort.
>
> This is getting annoying. It is your opinion that we should not add
> useful things because we haven't done so in the past, or because
> someone might want to do it slightly differently.
>
> I submitted it, Karel added it, period. There's no point continuing
> this argument.

Re: [PATCH] fstrim: add systemd units

[Markus Trippelsdorf]

On 2014.04.09 at 13:02 +0200, Karel Zak wrote:
> On Wed, Apr 09, 2014 at 12:07:56PM +0200, Ruediger Meier wrote:
> > Actually I think daily "fstrim -a" IS not a good idea for most of my 
> > systems
> 
> install service != enable (this is important detail, I'll never agree
> with automatically enabled services).
> 
> BTW, why IS not a good idea for your systems?

The fixed interval is problematic. There are SSD devices out there that
suffer (their flash cells die out faster) when they get trimmed too
often. A good rule of thumb is to trim once you have written the same
amount as you have free space on your device. Obviously, that interval
varies for every user (e.g. it's one week in my case).

-- 
Markus

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Wednesday 09 April 2014, Markus Trippelsdorf wrote:
> On 2014.04.09 at 13:02 +0200, Karel Zak wrote:
> > On Wed, Apr 09, 2014 at 12:07:56PM +0200, Ruediger Meier wrote:
> > > Actually I think daily "fstrim -a" IS not a good idea for most of
> > > my systems
> >
> > install service != enable (this is important detail, I'll never
> > agree with automatically enabled services).
> >
> > BTW, why IS not a good idea for your systems?
>
> The fixed interval is problematic. There are SSD devices out there
> that suffer (their flash cells die out faster) when they get trimmed
> too often. A good rule of thumb is to trim once you have written the
> same amount as you have free space on your device. Obviously, that
> interval varies for every user (e.g. it's one week in my case).

Is "mount -o discard" instead of fstrim interval more or less bad 
regarding lifetime?
And BTW does fstrim makes sense on non SSDs at all?

cu,
Rudi

Re: [PATCH] fstrim: add systemd units

[Markus Trippelsdorf]

On 2014.04.09 at 17:48 +0200, Ruediger Meier wrote:
> On Wednesday 09 April 2014, Markus Trippelsdorf wrote:
> > On 2014.04.09 at 13:02 +0200, Karel Zak wrote:
> > > On Wed, Apr 09, 2014 at 12:07:56PM +0200, Ruediger Meier wrote:
> > > > Actually I think daily "fstrim -a" IS not a good idea for most of
> > > > my systems
> > >
> > > install service != enable (this is important detail, I'll never
> > > agree with automatically enabled services).
> > >
> > > BTW, why IS not a good idea for your systems?
> >
> > The fixed interval is problematic. There are SSD devices out there
> > that suffer (their flash cells die out faster) when they get trimmed
> > too often. A good rule of thumb is to trim once you have written the
> > same amount as you have free space on your device. Obviously, that
> > interval varies for every user (e.g. it's one week in my case).
> 
> Is "mount -o discard" instead of fstrim interval more or less bad 
> regarding lifetime?

It really depends on the specific SSD model. But a cron job with fstrim
should do a better job in general.

> And BTW does fstrim makes sense on non SSDs at all?

No. (There are huge storage solutions with thin provisioning, that offer
trim support.)

-- 
Markus

Re: [PATCH] fstrim: add systemd units

[Theodore Ts'o]

On Wed, Apr 09, 2014 at 05:55:57PM +0200, Markus Trippelsdorf wrote:
> > > The fixed interval is problematic. There are SSD devices out there
> > > that suffer (their flash cells die out faster) when they get trimmed
> > > too often. A good rule of thumb is to trim once you have written the
> > > same amount as you have free space on your device. Obviously, that
> > > interval varies for every user (e.g. it's one week in my case).
> > 
> > Is "mount -o discard" instead of fstrim interval more or less bad 
> > regarding lifetime?

For those SSD's that have a problem, "mount -o discard" is a disaster.
Some turn into bricks, others will have a degraded flash cells, many
will cause extremely degraded performance for other processes.

What I usually tell people as far as who ask me for advice is that
once a week is usually sufficient, especially for most desktop and
server systems.  If you are running an extreme workload which is doing
a huge number of random writes, then sure, running fstrim more
frequently, or even using "mount -o discard" might make a lot more
sense --- especially if you are using PCIe attached flash.  But in
those cases, the system administrator might not want be willing to
tolerate the random latencies in performance that might show up when
fstrim is running (for pretty much all SATA and SAS attached SSD's out
there, they don't yet support queued trim, so each trim command
requires draining the NCQ queue, which is why sending trim commands,
whether via "mount -o discard" or via fstrim will incur a performance
penalty to whatever else might be trying to use the disk at the time).

I'll note BTW that even using "fstrim" could potentially brick an
especially inexpensive/trashy SSD, although the vendor for whose drive
had been most commonly accused of promulgating those to the world is
out of business (although there are probably plenty of those SSD's
still in use in various community distros' audiences.)

Cheers,

						- Ted

Re: [PATCH] fstrim: add systemd units

[Karel Zak]

On Wed, Apr 09, 2014 at 02:39:54PM -0400, Theodore Ts'o wrote:
> On Wed, Apr 09, 2014 at 05:55:57PM +0200, Markus Trippelsdorf wrote:
> > > > The fixed interval is problematic. There are SSD devices out there
> > > > that suffer (their flash cells die out faster) when they get trimmed
> > > > too often. A good rule of thumb is to trim once you have written the
> > > > same amount as you have free space on your device. Obviously, that
> > > > interval varies for every user (e.g. it's one week in my case).
> > > 
> > > Is "mount -o discard" instead of fstrim interval more or less bad 
> > > regarding lifetime?
> 
> For those SSD's that have a problem, "mount -o discard" is a disaster.
> Some turn into bricks, others will have a degraded flash cells, many
> will cause extremely degraded performance for other processes.
> 
> What I usually tell people as far as who ask me for advice is that
> once a week is usually sufficient, especially for most desktop and
> server systems.  If you are running an extreme workload which is doing
> a huge number of random writes, then sure, running fstrim more
> frequently, or even using "mount -o discard" might make a lot more
> sense --- especially if you are using PCIe attached flash.  But in
> those cases, the system administrator might not want be willing to
> tolerate the random latencies in performance that might show up when
> fstrim is running (for pretty much all SATA and SAS attached SSD's out
> there, they don't yet support queued trim, so each trim command
> requires draining the NCQ queue, which is why sending trim commands,
> whether via "mount -o discard" or via fstrim will incur a performance
> penalty to whatever else might be trying to use the disk at the time).
> 
> I'll note BTW that even using "fstrim" could potentially brick an
> especially inexpensive/trashy SSD, although the vendor for whose drive
> had been most commonly accused of promulgating those to the world is
> out of business (although there are probably plenty of those SSD's
> still in use in various community distros' audiences.)

 Thanks for the advices. 
 
 I have modified the systemd fstrim.timer (daily -> weekly) and added
 some notes to the man page.

    Karel

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

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Thursday 10 April 2014, Karel Zak wrote:
> On Wed, Apr 09, 2014 at 02:39:54PM -0400, Theodore Ts'o wrote:
> > On Wed, Apr 09, 2014 at 05:55:57PM +0200, Markus Trippelsdorf wrote:
> > > > > The fixed interval is problematic. There are SSD devices out
> > > > > there that suffer (their flash cells die out faster) when
> > > > > they get trimmed too often. A good rule of thumb is to trim
> > > > > once you have written the same amount as you have free space
> > > > > on your device. Obviously, that interval varies for every
> > > > > user (e.g. it's one week in my case).
> > > >
> > > > Is "mount -o discard" instead of fstrim interval more or less
> > > > bad regarding lifetime?
> >
> > For those SSD's that have a problem, "mount -o discard" is a
> > disaster. Some turn into bricks, others will have a degraded flash
> > cells, many will cause extremely degraded performance for other
> > processes.
> >
> > What I usually tell people as far as who ask me for advice is that
> > once a week is usually sufficient, especially for most desktop and
> > server systems.  If you are running an extreme workload which is
> > doing a huge number of random writes, then sure, running fstrim
> > more frequently, or even using "mount -o discard" might make a lot
> > more sense --- especially if you are using PCIe attached flash. 
> > But in those cases, the system administrator might not want be
> > willing to tolerate the random latencies in performance that might
> > show up when fstrim is running (for pretty much all SATA and SAS
> > attached SSD's out there, they don't yet support queued trim, so
> > each trim command requires draining the NCQ queue, which is why
> > sending trim commands, whether via "mount -o discard" or via fstrim
> > will incur a performance penalty to whatever else might be trying
> > to use the disk at the time).
> >
> > I'll note BTW that even using "fstrim" could potentially brick an
> > especially inexpensive/trashy SSD, although the vendor for whose
> > drive had been most commonly accused of promulgating those to the
> > world is out of business (although there are probably plenty of
> > those SSD's still in use in various community distros' audiences.)
>
>  Thanks for the advices.
>
>  I have modified the systemd fstrim.timer (daily -> weekly) and added
>  some notes to the man page.

Thanks, maybe we could add another minor change to "fstrim -a" itself. 
If possible it would be IMO useful to skip bind mounts to avoid 
trimming the same filesystem several times in a row like this:

$ grep "tmp" /etc/fstab
/dev/vg0/tmpdirs     /mnt/tmpdirs   ext4       acl,user_xattr     1 2
/mnt/tmpdirs/tmp     /tmp           none       bind               0 0
/mnt/tmpdirs/var/tmp /var/tmp       none       bind               0 0

$ ./fstrim -av
/tmp: 392 KiB (401408 bytes) trimmed
/var/tmp: 0 B (0 bytes) trimmed
/mnt/tmpdirs: 0 B (0 bytes) trimmed

Skipping bind mounts should still trim all mounted filesytems.

cu,
Rudi

Re: [PATCH] fstrim: add systemd units

[Karel Zak]

On Thu, Apr 10, 2014 at 11:17:04AM +0200, Ruediger Meier wrote:
> Thanks, maybe we could add another minor change to "fstrim -a" itself. 
> If possible it would be IMO useful to skip bind mounts to avoid 
> trimming the same filesystem several times in a row like this:
> 
> $ grep "tmp" /etc/fstab
> /dev/vg0/tmpdirs     /mnt/tmpdirs   ext4       acl,user_xattr     1 2
> /mnt/tmpdirs/tmp     /tmp           none       bind               0 0
> /mnt/tmpdirs/var/tmp /var/tmp       none       bind               0 0
> 
> $ ./fstrim -av
> /tmp: 392 KiB (401408 bytes) trimmed
> /var/tmp: 0 B (0 bytes) trimmed
> /mnt/tmpdirs: 0 B (0 bytes) trimmed
> 
> Skipping bind mounts should still trim all mounted filesytems.

Good idea point, but what about systems where the original
mountpoint is umounted?

 /dev/sda1  /foo    ext4    default
 /foo       /bar    none    bind

  # mount /foo
  # mount /bar
  # umount /foo 

the another story is that we use /proc/self/mountinfo where is
nothing about "bind". It would be probably better to de-duplicate the
list of the filesystems according to filesystem UUID or so.

I'll think about it.

Note all this is probably no problema for ext4 where according to Lukas is 
optimization to not call device trim command when there is nothing to trim.

    Karel

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

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Thursday 10 April 2014, Karel Zak wrote:
> On Thu, Apr 10, 2014 at 11:17:04AM +0200, Ruediger Meier wrote:
> > Thanks, maybe we could add another minor change to "fstrim -a"
> > itself. If possible it would be IMO useful to skip bind mounts to
> > avoid trimming the same filesystem several times in a row like
> > this:
> >
> > $ grep "tmp" /etc/fstab
> > /dev/vg0/tmpdirs     /mnt/tmpdirs   ext4       acl,user_xattr     1
> > 2 /mnt/tmpdirs/tmp     /tmp           none       bind              
> > 0 0 /mnt/tmpdirs/var/tmp /var/tmp       none       bind            
> >   0 0
> >
> > $ ./fstrim -av
> > /tmp: 392 KiB (401408 bytes) trimmed
> > /var/tmp: 0 B (0 bytes) trimmed
> > /mnt/tmpdirs: 0 B (0 bytes) trimmed
> >
> > Skipping bind mounts should still trim all mounted filesytems.
>
> Good idea point, but what about systems where the original
> mountpoint is umounted?
>
>  /dev/sda1  /foo    ext4    default
>  /foo       /bar    none    bind
>
>   # mount /foo
>   # mount /bar
>   # umount /foo

Nice, I thought that wouldn't be even possible to do.

> the another story is that we use /proc/self/mountinfo where is
> nothing about "bind". It would be probably better to de-duplicate the
> list of the filesystems according to filesystem UUID or so.
>
> I'll think about it.

Maybe you could borrow the filter from lsblk. With my fstab above it 
seems to skip the bind mounts:

NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda               8:0    0 232.9G  0 disk
├─sda1            8:1    0   512M  0 part /boot
└─sda2            8:2    0 232.4G  0 part
  ├─vg0-root    253:0    0    24G  0 lvm  /
  ├─vg0-swap    253:1    0     4G  0 lvm  [SWAP]
  └─vg0-tmpdirs 253:2    0 204.4G  0 lvm  /mnt/tmpdirs

> Note all this is probably no problema for ext4 where according to
> Lukas is optimization to not call device trim command when there is
> nothing to trim.

Yes, but maybe nice if we could avoid this anyway. Who know what happens 
exactly when there is already a heavy load queue and we want to place 
in several trims.

cu,
Rudi

Re: [PATCH] fstrim: add systemd units

[Ruediger Meier]

On Thursday 10 April 2014, Ruediger Meier wrote:
> On Thursday 10 April 2014, Karel Zak wrote:
> > On Thu, Apr 10, 2014 at 11:17:04AM +0200, Ruediger Meier wrote:
> > > Thanks, maybe we could add another minor change to "fstrim -a"
> > > itself. If possible it would be IMO useful to skip bind mounts to
> > > avoid trimming the same filesystem several times in a row like
> > > this:
> > >
> > > $ grep "tmp" /etc/fstab
> > > /dev/vg0/tmpdirs     /mnt/tmpdirs   ext4       acl,user_xattr    
> > > 1 2 /mnt/tmpdirs/tmp     /tmp           none       bind
> > > 0 0 /mnt/tmpdirs/var/tmp /var/tmp       none       bind
> > >   0 0
> > >
> > > $ ./fstrim -av
> > > /tmp: 392 KiB (401408 bytes) trimmed
> > > /var/tmp: 0 B (0 bytes) trimmed
> > > /mnt/tmpdirs: 0 B (0 bytes) trimmed
> > >
> > > Skipping bind mounts should still trim all mounted filesytems.
> >
> > Good idea point, but what about systems where the original
> > mountpoint is umounted?
> >
> >  /dev/sda1  /foo    ext4    default
> >  /foo       /bar    none    bind
> >
> >   # mount /foo
> >   # mount /bar
> >   # umount /foo
>
> Nice, I thought that wouldn't be even possible to do.
>
> > the another story is that we use /proc/self/mountinfo where is
> > nothing about "bind". It would be probably better to de-duplicate
> > the list of the filesystems according to filesystem UUID or so.
> >
> > I'll think about it.
>
> Maybe you could borrow the filter from lsblk. With my fstab above it
> seems to skip the bind mounts:
>
> NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> sda               8:0    0 232.9G  0 disk
> sda1            8:1    0   512M  0 part /boot
> sda2            8:2    0 232.4G  0 part
>   vg0-root    253:0    0    24G  0 lvm  /
>   vg0-swap    253:1    0     4G  0 lvm  [SWAP]
>   vg0-tmpdirs 253:2    0 204.4G  0 lvm  /mnt/tmpdirs

... seems the first mount wins. After umounting the origin:

$ umount /mnt/tmpdirs/
$ lsblk
NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda               8:0    0 232.9G  0 disk
├─sda1            8:1    0   512M  0 part /boot
└─sda2            8:2    0 232.4G  0 part
  ├─vg0-root    253:0    0    24G  0 lvm  /
  ├─vg0-swap    253:1    0     4G  0 lvm  [SWAP]
  └─vg0-tmpdirs 253:2    0 204.4G  0 lvm  /tmp
sr0              11:0    1  1024M  0 rom
loop0             7:0    0     1G  0 loop /mnt/a

cu,
Rudi

Re: [PATCH] fstrim: add systemd units

[Karel Zak]

On Tue, Apr 08, 2014 at 12:57:04PM +0200, Thomas Bächler wrote:
> > BTW fstrim.timer is missing in "make dist" tar ball.
> 
> Sorry, you are right. I'm a bit lost in this build system, Karel
> probably knows how to fix this.

 Fixed.

    Karel

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

Re: [PATCH] fstrim: add systemd units

[Thomas Bächler]

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

Am 08.04.2014 19:26, schrieb Karel Zak:
> On Tue, Apr 08, 2014 at 12:57:04PM +0200, Thomas Bächler wrote:
>>> BTW fstrim.timer is missing in "make dist" tar ball.
>>
>> Sorry, you are right. I'm a bit lost in this build system, Karel
>> probably knows how to fix this.
> 
>  Fixed.
> 
>     Karel

Thanks.



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