fstrim: add systemd units
PATCH 1/1 fstrim: add systemd units
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
sys-utils/.gitignore +1 -0
@@ -18,3 +18,4 @@ sparc32.8 sparc32bash.8 sparc64.8 x86_64.8 +fstrim.service
sys-utils/Makemodule.am +6 -0
@@ -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
sys-utils/fstrim.service.in new file +6 -0
@@ -0,0 +1,6 @@ +[Unit] +Description=Discard unused blocks + +[Service] +Type=oneshot +ExecStart=@sbindir@/fstrim -a
sys-utils/fstrim.timer new file +10 -0
@@ -0,0 +1,10 @@ +[Unit] +Description=Discard unused blocks once a day + +[Timer] +OnCalendar=daily +AccuracySec=1h +Persistent=true + +[Install] +WantedBy=multi-user.target
Signature · 1 line
1.9.1
Quoted 7 lines · Thomas Bächler
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.
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 10 lines · Karel Zak
Quoted 7 lines · Thomas Bächler
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.timerApplied, 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
Am 08.04.2014 12:25, schrieb Ruediger Meier:
Quoted 2 lines
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.
Quoted 1 line
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?
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 6 lines · On Tuesday 08 April 2014, Thomas B=C3=A4chler wrote:
Am 08.04.2014 12:25, schrieb Ruediger Meier:
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
Quoted 1 line
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
Quoted 5 lines · Ruediger Meier
Quoted 4 lines · Thomas Bächler
Am 08.04.2014 12:25, schrieb Ruediger Meier:
Quoted 2 lines
Hm, isn't this a bit over the top? Adding a script just to call "fstrim -a" automatically?
Quoted 8 lines
Quoted 2 lines
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.
Quoted 10 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 11 lines
Quoted 7 lines
Quoted 2 lines
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?
Quoted 23 lines
Quoted 4 lines
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.
Quoted 4 lines
Quoted 1 line
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 15 lines · Dave Reisner
Quoted 5 lines · Ruediger Meier
Quoted 4 lines · Thomas Bchler
Am 08.04.2014 12:25, schrieb Ruediger Meier:
Quoted 2 lines
Hm, isn't this a bit over the top? Adding a script just to call "fstrim -a" automatically?
Quoted 8 lines
Quoted 2 lines
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.
Quoted 3 lines
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).
Quoted 2 lines
You'd be better off comparing the proposed
timer and service unit to this.
?
Quoted 32 lines
Quoted 10 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
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).
Quoted 5 lines
Quoted 3 lines
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.
Quoted 12 lines
Quoted 12 lines
Quoted 4 lines
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.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
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
Karel Zak
maintainerQuoted 3 lines · Ruediger Meier
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
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 9 lines · Karel Zak
Quoted 3 lines · Ruediger Meier
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
Karel Zak
maintainerQuoted 2 lines · Ruediger Meier
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?
Quoted 3 lines
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).
Quoted 3 lines
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.
Quoted 3 lines
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
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 8 lines · Karel Zak
Quoted 2 lines · Ruediger Meier
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.
Quoted 8 lines
Quoted 3 lines
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?
Quoted 8 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Am 09.04.2014 14:12, schrieb Ruediger Meier:
Quoted 9 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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?
Quoted 1 line
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.
Quoted 11 lines · Thomas Bächler
Am 09.04.2014 14:12, schrieb Ruediger Meier:
Quoted 9 lines
Quoted 4 lines
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?
Quoted 4 lines
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.
Quoted 10 lines
It says exactly what it will do. Every one of your questions is answered.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 4 lines
Quoted 1 line
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
Am 09.04.2014 17:16, schrieb Ruediger Meier:
Quoted 12 lines · Thomas Bächler
Quoted 11 lines
Am 09.04.2014 14:12, schrieb Ruediger Meier:
Quoted 9 lines
Quoted 4 lines
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?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 3 lines
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).
Quoted 6 lines
Quoted 2 lines
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.
Quoted 16 lines · On Wednesday 09 April 2014, Thomas B=C3=A4chler wrote:
Am 09.04.2014 17:16, schrieb Ruediger Meier:
Quoted 15 lines · On Wednesday 09 April 2014, Thomas B=C3=A4chler wrote:
Quoted 14 lines
Am 09.04.2014 14:12, schrieb Ruediger Meier:
Quoted 10 lines
Quoted 5 lines
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:
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
'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.
Quoted 22 lines
Quoted 4 lines
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).
Quoted 6 lines
Quoted 2 lines
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.
Quoted 8 lines · Karel Zak
Quoted 2 lines · Ruediger Meier
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).
Signature · 1 line
Markus
Quoted 8 lines · Markus Trippelsdorf
Quoted 7 lines · Karel Zak
Quoted 2 lines · Ruediger Meier
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).
Quoted 7 lines
Quoted 1 line
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
Quoted 11 lines · Ruediger Meier
Quoted 10 lines · Markus Trippelsdorf
Quoted 8 lines · Karel Zak
Quoted 2 lines · Ruediger Meier
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?
Quoted 8 lines
Quoted 5 lines
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.
Quoted 1 line
And BTW does fstrim makes sense on non SSDs at all?
No. (There are huge storage solutions with thin provisioning, that offer trim support.)
Signature · 1 line
Markus
Quoted 8 lines · Markus Trippelsdorf
Quoted 8 lines
Quoted 5 lines
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
Karel Zak
maintainerQuoted 28 lines · Theodore Ts'o
Quoted 8 lines · Markus Trippelsdorf
Quoted 8 lines
Quoted 5 lines
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).
Quoted 5 lines
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
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 38 lines · Karel Zak
Quoted 31 lines · Theodore Ts'o
Quoted 9 lines · Markus Trippelsdorf
Quoted 9 lines
Quoted 6 lines
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).
Quoted 5 lines
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.)
Quoted 4 lines
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
Karel Zak
maintainerQuoted 9 lines · Ruediger Meier
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
Quoted 6 lines
$ ./fstrim -av /tmp: 392 KiB (401408 bytes) trimmed /var/tmp: 0 B (0 bytes) trimmed /mnt/tmpdirs: 0 B (0 bytes) trimmedSkipping 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
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 22 lines · Karel Zak
Quoted 11 lines · Ruediger Meier
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 0Quoted 6 lines
$ ./fstrim -av /tmp: 392 KiB (401408 bytes) trimmed /var/tmp: 0 B (0 bytes) trimmed /mnt/tmpdirs: 0 B (0 bytes) trimmedSkipping bind mounts should still trim all mounted filesytems.
Good idea point, but what about systems where the original mountpoint is umounted?
Quoted 6 lines
/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.
Quoted 5 lines
the another story is that we use
/proc/self/mountinfowhere 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
Quoted 3 lines
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
Quoted 41 lines · Ruediger Meier
Quoted 22 lines · Karel Zak
Quoted 11 lines · Ruediger Meier
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 0Quoted 6 lines
$ ./fstrim -av /tmp: 392 KiB (401408 bytes) trimmed /var/tmp: 0 B (0 bytes) trimmed /mnt/tmpdirs: 0 B (0 bytes) trimmedSkipping bind mounts should still trim all mounted filesytems.
Good idea point, but what about systems where the original mountpoint is umounted?
Quoted 6 lines
/dev/sda1 /foo ext4 default /foo /bar none bind# mount /foo # mount /bar # umount /fooNice, I thought that wouldn't be even possible to do.
Quoted 5 lines
the another story is that we use
/proc/self/mountinfowhere 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:
Quoted 7 lines
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 232.9G 0 disksda1 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
Karel Zak
maintainerQuoted 4 lines · Thomas Bächler
Quoted 1 line
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
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Am 08.04.2014 19:26, schrieb Karel Zak:
Quoted 9 lines · Thomas Bächler
Quoted 4 lines
Quoted 1 line
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.