I hope this doesn't sound stupid, but I'm totally new to systemd. And I am not familiar with systemd-journal. So, I did: systemctl start fstrim.service It seems to have worked. I got: systemctl status fstrim.service fstrim.service - Discard unused blocks Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) since [redacted]; 3min 50s ago Process: 1200 ExecStart=/sbin/fstrim -a (code=exited, status=0/SUCCESS) Main PID: 1200 (code=exited, status=0/SUCCESS) So thanks for the reply. On Sun, Dec 27, 2015 at 10:18 PM, Leonid Isaev < leonid.isaev@jila.colorado.edu> wrote:
On Sun, Dec 27, 2015 at 09:45:27PM -0500, Francis Gerund wrote:
Per the Arch wiki SSD page, I just enabled sysctl fstrim.timer, and then rebooted. I did not "enable" fstab.service. Now fstrim.timer is loaded, and active (but "waiting") and fstrim.service is loaded, but inactive. And the time stamp file the wiki mentions has a "0" size.
In /var/lib/systemd/timers? They all have zero size, it's their timestamp what matters.
So, do I have to wait (A WEEK!) to see if it works, or can I somehow now run fstrim.service manually to at least get it done once?
fstrim.service most likely ran on-boot, silently, so you haven't noticed. If you use systemd-journal, check it, otherwise just start fstrim.service w/o enabling it (or run its ExecStart cmdline).
Note: I could just add "discard" to /etc/fstab, but wouldn't that wear out the SSD faster than periodic trimming?
I don't know precise numbers, but IME none of those made a difference performace-wise. I'd say if SSD wear is a problem (i.e. if you estimate it within expected usage time of the device), just switch to a HDD.
HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D