Bug#732054: util-linux: Add cron job for regular SSD trimming
Le 15/02/18 à 16:53, Josh Triplett a écrit : Shouldn't be, no. I would suggest talking to the kernel folks, both Ben Hutchings for Debian, and upstream. I'll probably do that because I see something really weird here. Running fstrim twice, the 2nd time it says that there is nothing to trim, reboot, run fstrim, it says that it has trim the exact same number of byte that the 1st time on partitions that I'm sure nothing has been written/deleted on.
Bug#732054: util-linux: Add cron job for regular SSD trimming
On Tue, Feb 13, 2018 at 09:24:08AM +0100, Laurent Bigonville wrote: > Le 12/02/18 à 20:08, Josh Triplett a écrit : > > On February 12, 2018 12:22:45 PM EST, Laurent Bigonville > > wrote: > > > > > > Marco has opened #889668 to just install the .service and the .timer > > > file at the correct location but not enabling them by default. > > I can live with that. > > I'll try to see if I can provide a patch. > > > > I guess that it would be a good compromise for now, I also think that > > > putting these file in an example directory is a bit meh. > > > > > > But I'm seeing something weird, all my disks on my laptops have the > > > "discard" option set but for some reasons when running "fstrim -v -a" > > > it > > > still says that had trim data on all the FS. > > > > > > Do I miss something? > > Do you have an encrypted root filesystem? Or LVM? You need to take > > additional steps to enable discard if so. > > For LVM there is AFAIK nothing to do, the TRIM operation are passed to the > next layer by default, the only option in the config is to generate TRIM > when changing the size of a LV. > > For the cryptsetup/Luks level, I'm passing the discard option in the > crypttab. > > I just tried on my desktop at home (simple LVM without encryption) and I can > see the same thing behavior. > > Wouldn't that mean running fstrim is actually needed? Shouldn't be, no. I would suggest talking to the kernel folks, both Ben Hutchings for Debian, and upstream.
Bug#732054: util-linux: Add cron job for regular SSD trimming
Le 12/02/18 à 20:08, Josh Triplett a écrit : On February 12, 2018 12:22:45 PM EST, Laurent Bigonville wrote: Marco has opened #889668 to just install the .service and the .timer file at the correct location but not enabling them by default. I can live with that. I'll try to see if I can provide a patch. I guess that it would be a good compromise for now, I also think that putting these file in an example directory is a bit meh. But I'm seeing something weird, all my disks on my laptops have the "discard" option set but for some reasons when running "fstrim -v -a" it still says that had trim data on all the FS. Do I miss something? Do you have an encrypted root filesystem? Or LVM? You need to take additional steps to enable discard if so. For LVM there is AFAIK nothing to do, the TRIM operation are passed to the next layer by default, the only option in the config is to generate TRIM when changing the size of a LV. For the cryptsetup/Luks level, I'm passing the discard option in the crypttab. I just tried on my desktop at home (simple LVM without encryption) and I can see the same thing behavior. Wouldn't that mean running fstrim is actually needed?
Bug#732054: util-linux: Add cron job for regular SSD trimming
On February 12, 2018 12:22:45 PM EST, Laurent Bigonville wrote: >On Wed, 12 Jul 2017 20:22:00 -0700 Josh Triplett > >wrote: > > On Wed, Jul 12, 2017 at 07:57:28PM +0200, Andreas Henriksson wrote: > > > On Tue, Jul 11, 2017 at 08:23:07AM -0700, Josh Triplett wrote: > > > [...] > > > > Ideally, I would suggest that we start enabling the "discard" >option by >> > > default in d-i. That would also avoid spinning up a periodic cron >job > > > > that runs regardless of actual need or disk activity. > > > > > > This doesn't help systems that are being upgraded though, so IMHO > > > would be even more ideal if kernel just used it as default where > > > suitable. > > > > Agreed. I'd like to see the kernel use the more reasonable default. > > >> > > (One of the things I really wish we could do more easily is >eliminate >> > > the numerous cron jobs that simply wake up, realize they have no >work to > > > > do, and go back to sleep.) > > > >> > I see this problem but that's not my major concern. My personal >biggest >> > worry is about mixing mechanism (the util-linux tools) and policy >(cron >> > jobs, etc). I'd much rather see the two being separate and have >higher >> > level stuff put the policy in place rather than shipping the policy >in > > > an essential package. > > >> Agreed *completely*, and thank you for very clearly articulating this > > concern. > > > > > This is exactly the same reason why I'm not > > > entirely at ease with the suggestion in #855203 either. > > >> Agreed. Making that change would just move breakage around, fixing >some >> systems but breaking others. (There's a *reason* that job isn't run.) > > >> > Unfortunately I haven't been able to come up with a good package to > > > point the finger to where we should put this policy. > > > Suggestions would be very welcome! > > >> I think the right answer is always "fix the underlying package to >have >> the right default, rather than papering over it with configuration". >If >> we have some non-standard configuration we're shipping by default, we >> should figure out how to make some kind of automatic detection that >Just > > Works the new default and eliminate the configuration. > > > > > >Marco has opened #889668 to just install the .service and the .timer >file at the correct location but not enabling them by default. I can live with that. >I guess that it would be a good compromise for now, I also think that >putting these file in an example directory is a bit meh. > >But I'm seeing something weird, all my disks on my laptops have the >"discard" option set but for some reasons when running "fstrim -v -a" >it >still says that had trim data on all the FS. > >Do I miss something? Do you have an encrypted root filesystem? Or LVM? You need to take additional steps to enable discard if so. >Kind regards, > >Laurent Bigonville
Bug#732054: util-linux: Add cron job for regular SSD trimming
On Wed, 12 Jul 2017 20:22:00 -0700 Josh Triplett wrote: > On Wed, Jul 12, 2017 at 07:57:28PM +0200, Andreas Henriksson wrote: > > On Tue, Jul 11, 2017 at 08:23:07AM -0700, Josh Triplett wrote: > > [...] > > > Ideally, I would suggest that we start enabling the "discard" option by > > > default in d-i. That would also avoid spinning up a periodic cron job > > > that runs regardless of actual need or disk activity. > > > > This doesn't help systems that are being upgraded though, so IMHO > > would be even more ideal if kernel just used it as default where > > suitable. > > Agreed. I'd like to see the kernel use the more reasonable default. > > > > (One of the things I really wish we could do more easily is eliminate > > > the numerous cron jobs that simply wake up, realize they have no work to > > > do, and go back to sleep.) > > > > I see this problem but that's not my major concern. My personal biggest > > worry is about mixing mechanism (the util-linux tools) and policy (cron > > jobs, etc). I'd much rather see the two being separate and have higher > > level stuff put the policy in place rather than shipping the policy in > > an essential package. > > Agreed *completely*, and thank you for very clearly articulating this > concern. > > > This is exactly the same reason why I'm not > > entirely at ease with the suggestion in #855203 either. > > Agreed. Making that change would just move breakage around, fixing some > systems but breaking others. (There's a *reason* that job isn't run.) > > > Unfortunately I haven't been able to come up with a good package to > > point the finger to where we should put this policy. > > Suggestions would be very welcome! > > I think the right answer is always "fix the underlying package to have > the right default, rather than papering over it with configuration". If > we have some non-standard configuration we're shipping by default, we > should figure out how to make some kind of automatic detection that Just > Works the new default and eliminate the configuration. > > Marco has opened #889668 to just install the .service and the .timer file at the correct location but not enabling them by default. I guess that it would be a good compromise for now, I also think that putting these file in an example directory is a bit meh. But I'm seeing something weird, all my disks on my laptops have the "discard" option set but for some reasons when running "fstrim -v -a" it still says that had trim data on all the FS. Do I miss something? Kind regards, Laurent Bigonville
Bug#732054: util-linux: Add cron job for regular SSD trimming
On Wed, Jul 12, 2017 at 07:57:28PM +0200, Andreas Henriksson wrote: > On Tue, Jul 11, 2017 at 08:23:07AM -0700, Josh Triplett wrote: > [...] > > Ideally, I would suggest that we start enabling the "discard" option by > > default in d-i. That would also avoid spinning up a periodic cron job > > that runs regardless of actual need or disk activity. > > This doesn't help systems that are being upgraded though, so IMHO > would be even more ideal if kernel just used it as default where > suitable. Agreed. I'd like to see the kernel use the more reasonable default. > > (One of the things I really wish we could do more easily is eliminate > > the numerous cron jobs that simply wake up, realize they have no work to > > do, and go back to sleep.) > > I see this problem but that's not my major concern. My personal biggest > worry is about mixing mechanism (the util-linux tools) and policy (cron > jobs, etc). I'd much rather see the two being separate and have higher > level stuff put the policy in place rather than shipping the policy in > an essential package. Agreed *completely*, and thank you for very clearly articulating this concern. > This is exactly the same reason why I'm not > entirely at ease with the suggestion in #855203 either. Agreed. Making that change would just move breakage around, fixing some systems but breaking others. (There's a *reason* that job isn't run.) > Unfortunately I haven't been able to come up with a good package to > point the finger to where we should put this policy. > Suggestions would be very welcome! I think the right answer is always "fix the underlying package to have the right default, rather than papering over it with configuration". If we have some non-standard configuration we're shipping by default, we should figure out how to make some kind of automatic detection that Just Works the new default and eliminate the configuration.
Bug#732054: util-linux: Add cron job for regular SSD trimming
On Tue, Jul 11, 2017 at 01:44:23PM -0400, Phil Susi wrote: > On 7/11/2017 11:23 AM, Josh Triplett wrote: > >> There are two main methods for doing this, synchronously using the > >> "discard" mount option or asynchronously using fstrim [2]. Colin King did > >> some extensive benchmarking and found that on desktops and servers you > >> usually want a cron'ed fstrim [3]. > > > > This assumes that you can handle a disk-heavy job running via cron, > > rather than distributing the overhead over time. (That link mentions > > fstrim running for a long time even when run on a daily basis, let alone > > weekly.) Sometimes you want to maximize peak performance at the cost of > > extra overhead at specific times; sometimes you want consistent > > performance and no downward spikes. > > > > Ideally, I would suggest that we start enabling the "discard" option by > > default in d-i. That would also avoid spinning up a periodic cron job > > that runs regardless of actual need or disk activity. > > > > (One of the things I really wish we could do more easily is eliminate > > the numerous cron jobs that simply wake up, realize they have no work to > > do, and go back to sleep.) > > I assume that since this bug is still open in Debian, that Ubuntu > diverged here since we've had the fstrim cron job for a few years now. > I even came across a bug report not too long ago saying that it trashes > OCFS filesystems running on a SAN. Yeah, I've had it trash a filesystem as well. That was a kernel bug that has since been fixed, so I didn't want to use that as an argument against, but I definitely know people who thought they'd mitigated that bug by disabling "discard" yet had their filesystems trashed because of the fstrim cron job.
Bug#732054: util-linux: Add cron job for regular SSD trimming
On Tue, Jul 11, 2017 at 08:23:07AM -0700, Josh Triplett wrote: [...] > Ideally, I would suggest that we start enabling the "discard" option by > default in d-i. That would also avoid spinning up a periodic cron job > that runs regardless of actual need or disk activity. This doesn't help systems that are being upgraded though, so IMHO would be even more ideal if kernel just used it as default where suitable. > (One of the things I really wish we could do more easily is eliminate > the numerous cron jobs that simply wake up, realize they have no work to > do, and go back to sleep.) I see this problem but that's not my major concern. My personal biggest worry is about mixing mechanism (the util-linux tools) and policy (cron jobs, etc). I'd much rather see the two being separate and have higher level stuff put the policy in place rather than shipping the policy in an essential package. This is exactly the same reason why I'm not entirely at ease with the suggestion in #855203 either. (Also the fact that once this is shipped, we probably have to keep it around forever.) Unfortunately I haven't been able to come up with a good package to point the finger to where we should put this policy. Suggestions would be very welcome! Regards, Andreas Henriksson
Bug#732054: util-linux: Add cron job for regular SSD trimming
On 7/11/2017 11:23 AM, Josh Triplett wrote: >> There are two main methods for doing this, synchronously using the >> "discard" mount option or asynchronously using fstrim [2]. Colin King did >> some extensive benchmarking and found that on desktops and servers you >> usually want a cron'ed fstrim [3]. > > This assumes that you can handle a disk-heavy job running via cron, > rather than distributing the overhead over time. (That link mentions > fstrim running for a long time even when run on a daily basis, let alone > weekly.) Sometimes you want to maximize peak performance at the cost of > extra overhead at specific times; sometimes you want consistent > performance and no downward spikes. > > Ideally, I would suggest that we start enabling the "discard" option by > default in d-i. That would also avoid spinning up a periodic cron job > that runs regardless of actual need or disk activity. > > (One of the things I really wish we could do more easily is eliminate > the numerous cron jobs that simply wake up, realize they have no work to > do, and go back to sleep.) I assume that since this bug is still open in Debian, that Ubuntu diverged here since we've had the fstrim cron job for a few years now. I even came across a bug report not too long ago saying that it trashes OCFS filesystems running on a SAN.
Bug#732054: util-linux: Add cron job for regular SSD trimming
On Fri, 13 Dec 2013 11:11:44 +0100 Martin Pitt wrote: > Modern SSDs need regular TRIMming [1] to retain their performance. > Without it, write performance severely (like 1/50th) goes down over > time, as writing a single block incurs reading/updating/writing back > several physical blocks. > > There are two main methods for doing this, synchronously using the > "discard" mount option or asynchronously using fstrim [2]. Colin King did > some extensive benchmarking and found that on desktops and servers you > usually want a cron'ed fstrim [3]. This assumes that you can handle a disk-heavy job running via cron, rather than distributing the overhead over time. (That link mentions fstrim running for a long time even when run on a daily basis, let alone weekly.) Sometimes you want to maximize peak performance at the cost of extra overhead at specific times; sometimes you want consistent performance and no downward spikes. Ideally, I would suggest that we start enabling the "discard" option by default in d-i. That would also avoid spinning up a periodic cron job that runs regardless of actual need or disk activity. (One of the things I really wish we could do more easily is eliminate the numerous cron jobs that simply wake up, realize they have no work to do, and go back to sleep.)
Bug#732054: util-linux: Add cron job for regular SSD trimming
2nd version of the patch diff -Nru util-linux-2.29.1/debian/changelog util-linux-2.29.1/debian/changelog --- util-linux-2.29.1/debian/changelog 2017-01-20 17:33:41.0 +0100 +++ util-linux-2.29.1/debian/changelog 2017-01-22 16:30:31.0 +0100 @@ -1,3 +1,9 @@ +util-linux (2.29.1-2) UNRELEASED; urgency=medium + + * Enable weekly fstrim cronjob (Closes: #732054) + + -- Laurent Bigonville Sun, 22 Jan 2017 16:30:31 +0100 + util-linux (2.29.1-1) unstable; urgency=medium * Bump versions in shlibs to match recent symbols updates diff -Nru util-linux-2.29.1/debian/rules util-linux-2.29.1/debian/rules --- util-linux-2.29.1/debian/rules 2017-01-20 17:33:41.0 +0100 +++ util-linux-2.29.1/debian/rules 2017-01-22 16:30:31.0 +0100 @@ -174,6 +174,16 @@ override_dh_fixperms: dh_fixperms -i -s -Xusr/bin/wall -Xbin/mount -Xbin/umount +override_dh_installcron: +ifeq ($(DEB_HOST_ARCH_OS),linux) + dh_installcron -putil-linux --name=fstrim +endif + dh_installcron + +override_dh_systemd_start: + dh_systemd_start -putil-linux --no-start fstrim.service + dh_systemd_start -Nutil-linux + override_dh_auto_test: ifeq ($(DEB_HOST_ARCH_OS), linux) dh_auto_test --max-parallel=1 diff -Nru util-linux-2.29.1/debian/util-linux.fstrim.cron.weekly util-linux-2.29.1/debian/util-linux.fstrim.cron.weekly --- util-linux-2.29.1/debian/util-linux.fstrim.cron.weekly 1970-01-01 01:00:00.0 +0100 +++ util-linux-2.29.1/debian/util-linux.fstrim.cron.weekly 2017-01-22 16:30:31.0 +0100 @@ -0,0 +1,8 @@ +#!/bin/sh +# trim all mounted file systems which support it + +set -e + +if [ ! -d /run/systemd/system -a -x /sbin/fstrim ]; then + /sbin/fstrim -a > /dev/null +fi diff -Nru util-linux-2.29.1/debian/util-linux.install util-linux-2.29.1/debian/util-linux.install --- util-linux-2.29.1/debian/util-linux.install 2017-01-20 17:33:41.0 +0100 +++ util-linux-2.29.1/debian/util-linux.install 2017-01-22 14:24:18.0 +0100 @@ -7,8 +7,8 @@ [linux-any] sbin/mkswap [!linux-any] debian/tmp/sbin/mkswap => /sbin/mkswap.linux # weekly fstrim only available on linux -[linux-any] lib/systemd/system/fstrim.timer => /usr/share/doc/util-linux/examples/fstrim.timer -[linux-any] lib/systemd/system/fstrim.service => /usr/share/doc/util-linux/examples/fstrim.service +[linux-any] lib/systemd/system/fstrim.timer +[linux-any] lib/systemd/system/fstrim.service bin/more bin/mountpoint sbin/agetty
Bug#732054: util-linux: Add cron job for regular SSD trimming
Package: util-linux Followup-For: Bug #732054 Hi, Please find a patch attached in the this mail. Cheers, Laurent Bigonville -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages util-linux depends on: ii init-system-helpers 1.47 ii libblkid12.29.1-1 ii libc62.24-9 ii libfdisk12.29.1-1 ii libmount12.29.1-1 ii libncursesw5 6.0+20161126-1 ii libpam0g 1.1.8-3.5 ii libselinux1 2.6-3 ii libsmartcols12.29.1-1 ii libsystemd0 232-12 ii libtinfo56.0+20161126-1 ii libudev1 232-12 ii libuuid1 2.29.1-1 ii zlib1g 1:1.2.8.dfsg-4 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.0-2 ii kbd 2.0.3-2 ii util-linux-locales 2.29.1-1 -- debconf information excluded diff -Nru util-linux-2.29.1/debian/changelog util-linux-2.29.1/debian/changelog --- util-linux-2.29.1/debian/changelog 2017-01-20 17:33:41.0 +0100 +++ util-linux-2.29.1/debian/changelog 2017-01-22 16:30:31.0 +0100 @@ -1,3 +1,9 @@ +util-linux (2.29.1-2) UNRELEASED; urgency=medium + + * Enable weekly fstrim cronjob (Closes: #732054) + + -- Laurent Bigonville Sun, 22 Jan 2017 16:30:31 +0100 + util-linux (2.29.1-1) unstable; urgency=medium * Bump versions in shlibs to match recent symbols updates diff -Nru util-linux-2.29.1/debian/rules util-linux-2.29.1/debian/rules --- util-linux-2.29.1/debian/rules 2017-01-20 17:33:41.0 +0100 +++ util-linux-2.29.1/debian/rules 2017-01-22 16:23:21.0 +0100 @@ -174,6 +174,14 @@ override_dh_fixperms: dh_fixperms -i -s -Xusr/bin/wall -Xbin/mount -Xbin/umount +override_dh_installcron: + dh_installcron -putil-linux --name=fstrim + dh_installcron + +override_dh_systemd_start: + dh_systemd_start -putil-linux --no-start fstrim.service + dh_systemd_start -Nutil-linux + override_dh_auto_test: ifeq ($(DEB_HOST_ARCH_OS), linux) dh_auto_test --max-parallel=1 diff -Nru util-linux-2.29.1/debian/util-linux.fstrim.cron.weekly util-linux-2.29.1/debian/util-linux.fstrim.cron.weekly --- util-linux-2.29.1/debian/util-linux.fstrim.cron.weekly 1970-01-01 01:00:00.0 +0100 +++ util-linux-2.29.1/debian/util-linux.fstrim.cron.weekly 2017-01-22 16:08:33.0 +0100 @@ -0,0 +1,7 @@ +#!/bin/sh + +set -e + +if [ ! -d /run/systemd/system -a -x /sbin/fstrim ]; then + fstrim -a > /dev/null +fi diff -Nru util-linux-2.29.1/debian/util-linux.install util-linux-2.29.1/debian/util-linux.install --- util-linux-2.29.1/debian/util-linux.install 2017-01-20 17:33:41.0 +0100 +++ util-linux-2.29.1/debian/util-linux.install 2017-01-22 14:24:18.0 +0100 @@ -7,8 +7,8 @@ [linux-any] sbin/mkswap [!linux-any] debian/tmp/sbin/mkswap => /sbin/mkswap.linux # weekly fstrim only available on linux -[linux-any] lib/systemd/system/fstrim.timer => /usr/share/doc/util-linux/examples/fstrim.timer -[linux-any] lib/systemd/system/fstrim.service => /usr/share/doc/util-linux/examples/fstrim.service +[linux-any] lib/systemd/system/fstrim.timer +[linux-any] lib/systemd/system/fstrim.service bin/more bin/mountpoint sbin/agetty
Bug#732054: util-linux: Add cron job for regular SSD trimming
tag 732054 patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch trusty
Martin Pitt [2013-12-13 11:11 +0100]:
> I propose to add a cron.d job to util-linux by default which regularly
> trims SSD partitions if they support it and don't already have the
> "discard" mount option set.
That's the debdiff I uploaded to Ubuntu for this.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
diff -u util-linux-2.20.1/debian/changelog util-linux-2.20.1/debian/changelog
--- util-linux-2.20.1/debian/changelog
+++ util-linux-2.20.1/debian/changelog
@@ -1,3 +1,18 @@
+util-linux (2.20.1-5.1ubuntu11) trusty; urgency=medium
+
+ * Regularly trim SSDs automatically:
+- Add debian/fstrim-all: Script to detect which mounted partitions
+ need/support trimming, and call fstrim(8) on all of them. Installed into
+ /usr/sbin/.
+- Add debian/fstrim-all.8: Manpage for the above.
+- Add debian/fstrim-all.cron: Trivial shell script to call fstrim-all,
+ so that admins can easily adjust/disable it. Installed as
+ /etc/cron.weekly/fstrim.
+- See https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming
+- Closes: #732054
+
+ -- Martin Pitt Mon, 16 Dec 2013 08:59:40 +0100
+
util-linux (2.20.1-5.1ubuntu10) trusty; urgency=low
* Fix memory leak on configure.ac for autopoint. Closes: #724255.
diff -u util-linux-2.20.1/debian/rules util-linux-2.20.1/debian/rules
--- util-linux-2.20.1/debian/rules
+++ util-linux-2.20.1/debian/rules
@@ -179,6 +179,12 @@
cd debian/util-linux/sbin ; mv mkswap mkswap.linux
cd debian/util-linux/usr/share/man/man8 ; mv mkswap.8 mkswap.linux.8
endif
+ # automatically trim SSD drives
+ if [ -f debian/util-linux/sbin/fstrim ] ; then \
+ install -m 755 debian/fstrim-all debian/util-linux/sbin; \
+ install -m 644 debian/fstrim-all.8
debian/util-linux/usr/share/man/man8; \
+ install -D -m 755 debian/fstrim-all.cron
debian/util-linux/etc/cron.weekly/fstrim; \
+ fi
dh_compress -i -s
dh_fixperms -i -s -Xusr/bin/wall -Xbin/mount -Xbin/umount
rm -rf debian/*-udeb/usr/share/doc
only in patch2:
unchanged:
--- util-linux-2.20.1.orig/debian/fstrim-all
+++ util-linux-2.20.1/debian/fstrim-all
@@ -0,0 +1,56 @@
+#!/bin/sh
+#
+# Call fstrim on mounted partitions to maintain write performance.
+# This is only relevant for SSD drives, see
+# http://wiki.ubuntuusers.de/SSD/TRIM
+set -e
+
+# needs /proc
+[ -r /proc/mounts ] || exit 0
+
+# these file systems support trimming
+SUPPORTED_FS="ext3 ext4 xfs btrfs"
+
+# arguments:
+contains() {
+[ "${1#*$2}" != "$1" ]
+}
+
+DONE=''
+while read DEV MOUNT FSTYPE OPTIONS REST; do
+# only consider /dev/*
+[ "${DEV#/dev}" != "$DEV" ] || continue
+# ignore mounts with "discard", they TRIM already
+if contains "$OPTIONS" discard; then continue; fi
+# only consider supported file systems
+if ! contains "$SUPPORTED_FS" "$FSTYPE"; then continue; fi
+
+# did we see this already? we need to resolve symlinks
+# for/dev/disks/by-{label,uuid}, etc.
+REALDEV=`readlink -f $DEV`
+if contains "$DONE" " $REALDEV "; then continue; fi
+DONE="$DONE $REALDEV "
+
+#echo "device $DEV real $REALDEV mountpoint $MOUNT fstype $FSTYPE"
+
+# check if that device supports trim; this does not work for devmapper,
+# though, so just call fstrim on those without the extra check and ignore
+# errors; for cryptsetup and LVM you also need extra configuration options
+# to propagate discards, which the admin might have turned off
+unset SILENT_FAILURE
+if [ "${REALDEV#/dev/dm-}" != "$REALDEV" ]; then
+#echo "device $DEV is on devmapper, skipping TRIM feature check"
+SILENT_FAILURE=1
+else
+if ! contains "`hdparm -I $REALDEV`" "TRIM"; then
+#echo "device $DEV does not support trimming"
+continue
+fi
+fi
+
+if [ -n "$SILENT_FAILURE" ]; then
+fstrim $MOUNT 2>/dev/null || true
+else
+fstrim $MOUNT
+fi
+done < /proc/mounts
only in patch2:
unchanged:
--- util-linux-2.20.1.orig/debian/fstrim-all.8
+++ util-linux-2.20.1/debian/fstrim-all.8
@@ -0,0 +1,24 @@
+.TH fstrim-all 8 "Dec 2013" "" "Debian Administrator's Manual"
+
+.SH NAME
+fstrim-all \- call fstrim on all mounted file systems which support it
+
+.SH DESCRIPTION
+
+SSD drives need to be TRIMed, i. e. they need to be told which blocks the OS
+considers as "unused" (i. e. from deleted files). Withouth this, the write
+speed on SSDs becomes slower over time.
+
+.B fstrim\-all
+detects which mounted partitions belong to drives that need/support trimming,
+and calls
+.BR fstrim (1)
+on them.
+
+It is meant to be called from cron. There is no output on success.
+
+.SH AUTHOR
+Martin Pitt
+
+.SH SEE ALSO
+.BR fstrim (8)
only in patch2:
unchanged:
--- util-linux-2.
Bug#732054: util-linux: Add cron job for regular SSD trimming
Package: util-linux Version: 2.20.1-5.5 Severity: wishlist Hello, Modern SSDs need regular TRIMming [1] to retain their performance. Without it, write performance severely (like 1/50th) goes down over time, as writing a single block incurs reading/updating/writing back several physical blocks. There are two main methods for doing this, synchronously using the "discard" mount option or asynchronously using fstrim [2]. Colin King did some extensive benchmarking and found that on desktops and servers you usually want a cron'ed fstrim [3]. I propose to add a cron.d job to util-linux by default which regularly trims SSD partitions if they support it and don't already have the "discard" mount option set. We'll put a cron job like that into the upcoming Ubuntu 14.04 LTS so that this kind of housekeeping will always be done unless the admin already set it up manually. Is that something you'd consider for Debian as well? My current script is at [4], you can just put it into /etc/cron.daily/ or .weekly/ (but for an official fix I'd rather use cron.d, so that it's easier to adjust by admins) Thanks, Martin [1] http://en.wikipedia.org/wiki/Trim_%28computing%29 [2] http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support [3] https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming [4] http://people.canonical.com/~pitti/scripts/fstrim -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
