fstrim with Buster

[kalle123]

On https://wiki.debian.org/SSDOptimization I find this note

Enable weekly trim (not needed on buster)

But on a test installation of Buster on a 120 GB SSD I don't see fstrim active.

Found no further info ....

[Head_on_a_Stick]

Code: Select all

# apt install util-linux
# systemctl enable --now fstrim.timer
systemctl list-timers

[kalle123]

@Head_on_a_Stick, thank you

But that is contrary to what that wiki article says

Enable weekly trim (not needed on buster)

[Head_on_a_Stick]

But that is contrary to what that wiki article says

That wiki page is full of dubious advice. For example, there hasn't been any need to reduce writes to the SSD for a while now because drive longevity is greatly improved compared to the early production models.

[kalle123]

But that is contrary to what that wiki article says

That wiki page is full of dubious advice. For example, there hasn't been any need to reduce writes to the SSD for a while now because drive longevity is greatly improved compared to the early production models.

Not only that page. Same, when you start looking for advice on the sources.list on Buster.

Different wiki pages give different information ....

[Head_on_a_Stick]

Different wiki pages give different information

Yes, that can be a problem with public wiki resources, I grew bored of fighting with the ArchWiki maintainers some time ago but the same problem exists there as well.

FWIW, just treat the SSD as if it were a spinning rust drive, they don't need any special treatment.

[p.H]

FWIW, just treat the SSD as if it were a spinning rust drive, they don't need any special treatment.

What about TRIM, defragmentation and proper alignment ?

[Head_on_a_Stick]

What about TRIM

I think fstrim.timer should be sufficient, check fstrim(8) for more on this.

defragmentation

Isn't fragmentation a spinning rust "feature"?

I don't think defragmentation is needed for an SSD, am I wrong?

proper alignment

Don't most disk partitioning utilities align to the 4K standard automatically?

[kalle123]

I do these steps with an SSD.

(Did it with Buster, from my notes ...)

- CHECK alignment

Code: Select all

$ sudo parted /dev/sda align-check opt

Partitionnumber? 1                                                       
1 aligned


- ADD noatime

Code: Select all

- Add the "noatime"

(or "relatime") mount option in /etc/fstab, to disable (or significantly reduce) disk writes whenever a file is read.


- ENABLE weekly trim

Code: Select all

$ sudo cp /usr/share/doc/util-linux/examples/fstrim.{service,timer} /etc/systemd/system

$ sudo systemctl enable fstrim.timer


- CHECKING trim

Code: Select all

$ systemctl status fstrim.timer

View fstrim.timer status:

$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Thu 2018-07-05 05:45:11 BST; 4h 42min ago
  Trigger: Mon 2018-07-09 00:00:00 BST; 3 days left
     Docs: man:fstrim
Start/Stop/Restart fstrim.timer:
(immediate activate/deactivate/reactivate, does not change startup status)


$ sudo systemctl [start/stop/restart] fstrim.timer
Enable/Disable fstrim.timer:
(add to/remove from startup, does not change immediate active status)

$ sudo systemctl [enable/disable] fstrim.timer
View fstrim.timer configuration:

$ systemctl cat fstrim.timer
# /lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target
View fstrim.service configuration:

$ systemctl cat fstrim.service
# /lib/systemd/system/fstrim.service
[Unit]
Description=Discard unused blocks

[Service]
Type=oneshot
ExecStart=/sbin/fstrim -av
View related systemd journal entries:

$ journalctl -u fstrim.timer
Jul 04 14:18:41 user-laptop systemd[1]: Started Discard unused blocks once a week.
Jul 04 21:59:26 user-laptop systemd[1]: Stopped Discard unused blocks once a week.
etc...

$ journalctl -u fstrim.service
Jun 25 10:59:44 user-laptop systemd[1]: Starting Discard unused blocks...
Jun 25 10:59:48 user-laptop fstrim[955]: /: 92.5 GiB (99335237632 bytes) trimmed
Jun 25 10:59:48 user-laptop systemd[1]: Started Discard unused blocks.
-- Reboot --
Jul 02 04:27:41 user-laptop systemd[1]: Starting Discard unused blocks...
Jul 02 04:27:46 user-laptop fstrim[1032]: /: 92.3 GiB (99150807040 bytes) trimmed
Jul 02 04:27:46 user-laptop systemd[1]: Started Discard unused blocks.
etc...

- CHECK Low-Latency IO-Scheduler

Code: Select all

$ grep . /sys/block/sd?/queue/rotational

/sys/block/sda/queue/rotational:1
/sys/block/sdb/queue/rotational:1
/sys/block/sdc/queue/rotational:0   <=== Only this is SSD!

- CHANGE Low-Latency IO-Scheduler

Code: Select all

# echo deadline > /sys/block/$YOURDRIVE/queue/scheduler

- TEST Low-Latency IO-Scheduler

Code: Select all

$ grep . /sys/block/sd?/queue/scheduler
/sys/block/sda/queue/scheduler:noop deadline [cfq]
/sys/block/sdb/queue/scheduler:noop deadline [cfq]
/sys/block/sdc/queue/scheduler:noop [deadline] cfq  <== That is!

[Head_on_a_Stick]

- Add the "noatime"

^ Absolutely not needed, relatime has been the default for ext4 since kernel 2.6.30 and that should be sufficient, even if excess writes were a concern (which they're not with any modern production SSD[1]).

Also, noatime breaks mutt, which is sad.

[1] https://techreport.com/review/27909/the ... e-all-dead ← that's from 2015, I think the drives have improved since then.

[kalle123]

The rest is ok?

[bw123]

On https://wiki.debian.org/SSDOptimization I find this note

Enable weekly trim (not needed on buster)

But on a test installation of Buster on a 120 GB SSD I don't see fstrim active.

Found no further info ....

The wiki might be referring to the fact that fstrim.timer does not have to be copied manually from /usr/share/doc/util-linux/examples

starting with buster.
https://packages.debian.org/search?suit ... trim.timer

Did you check the documentation mentioned in the changelog?
https://metadata.ftp-master.debian.org/ ... _changelog

util-linux (2.32.1-0.2) unstable; urgency=medium
... * debian/util-linux.README.Debian: Add information about the fstrim.timer

[Head_on_a_Stick]

Try some benchmarks for the I/O schedulers, my buster system defaults to mq-deadline, which is well suited to SSDs (AFAIK).

Also, there is no need to copy fstrim.{timer,service}, my buster system has them in /lib/systemd/system so the .timer just needs to be enabled. There is no /usr/share/doc/util-linux/examples/fstrim.{service,timer} in buster, my guide with the copy command was for jessie & stretch.

EDIT: bw123 beat me to it

[bw123]

I think there is an active IRC for debian wiki, if OP wants to help clear up the language. Documentation can always be improved.
maybe #debian-www ?

[kalle123]

The wiki might be referring to the fact that fstrim.timer does not have to be copied manually from /usr/share/doc/util-linux/examples

I read it the other way, but English is not my native language.

But I am glad we can discuss those settings and checks.