Why is ssd trim disabled by default?

Ahh, sorry, I did with sudo. Edited my post.

I found the issue but I’m not sure why that is. In /etc/systemd/system/ I have a file named timers.target.wants. The content of this file is:

[Unit]
Description=Generate mirrorlist weekly

[Timer]
OnCalendar=Thu *-*-* 7:00:00
RandomizedDelaySec=15h
Persistent=true

[Install]
WantedBy=timers.target

Now when I want to enable the fstrim.timer it gives me this error:

/etc/systemd/system/timers.target.wants/fstrim.timer: Not a directory

So it requires timers.target.wants to be a folder so it can symlink the timer file inside the folder. Obviously, this isn’t possible now the question is what to do. Why do I even have that file with the mirrorlist timer and why wasn’t it placed inside a subfolder too? Can I just delete it? I don’t want to screw something up but a new mirrorlist have to be generated once every week anyway.

Another question is, why am I the only one having this issue, lol? I never did anything manually inside systemd so the system created that filewithout a subfolder.

EDIT:
seems like the symlink comes from /usr/lib/systemd/system/pamac-mirrorlist.timer and is actually not even loaded. I wonder how this happened but I’m just gonna delete the symlink in /etc/

Yes, /etc/systemd/system/timers.target.wants should be a directory, and inside of it, you should have the following files, which are actually symlinks… :arrow_down:

lrwxrwxrwx 1 root root 36 May 21  2019 fstrim.timer -> /usr/lib/systemd/system/fstrim.timer
lrwxrwxrwx 1 root root 46 Nov 18 18:43 pamac-cleancache.timer -> /usr/lib/systemd/system/pamac-cleancache.timer
lrwxrwxrwx 1 root root 46 Nov 18 18:43 pamac-mirrorlist.timer -> /usr/lib/systemd/system/pamac-mirrorlist.timer

With the information above, you should be able to rectify the situation. :wink:

Only you know what you did. It may have been a result of some earlier fiddling you’ve done, or maybe because of some strange installation or update procedure you’ve attempted. For instance, some people install Debian’s apt/apt-get in Manjaro and use that for updating the system, with breakage as a result.

I’m not saying you did that, but something caused that weird situation on your system. :thinking:

2 Likes

Yeah, who knows how this happened (and yeah, I never tried something with apt or tried to biuld a debian package ^^). In anyway, deleting the file did the trick and I successfully enabled the fstrim.timer.
Thanks for the tip with the 2 pamac timers, I enabled them too and they are in the subfolder now, lol.

1 Like

You’re not the only one.

I did a clean install on my desktop system (stable, KDE) nearly three weeks ago and noticed that there was no “discard” in the fstab. So I blythly thought it must be using fstrim now (which wasn’t the case with my two year old install on my laptop where the discard option was in the fstab from the start … which I thought was odd).

Today I was updating the laptop and thought I would delete the discard option in the fstab and turn on the fstrim option only to discover the same problem as above. Then I thought I’d have another look at the desktop install only to find it’s got the same problem, only it’s worse because there is no discard and no fstrim … not good. :face_with_raised_eyebrow:

Obviously there is a bug here.

I see, good to know. I wonder if there are more users with that problem. Not everyone posts in the forum after all.

Just for the record, I don’t have the discard option either in my fstab.

Same here with a KDE install.

The timer is set in the iso-profiles, but manjaro-tools-iso doesn’t seem to support timers. This feature needs to be implemented.

1 Like

Besides trim, what other timers need to be enabled?

Workaround: Would it be possible to put the symbolic link manually in the desktop overlay? In the right path of course.

That probably should work as a workaround

I was checking the trim status in Manjaro Gnome when I found I had the same error about fstrim.timer ‘not a directory’.

I searched the forum for a solution and corrected it with the information in the post by Aragorn. The OS installation date was Jun 1, 2019.

I checked a second Manjaro Gnome installation that was done on Sep 13, 2019. It already had the correct file system structure and trim was already enabled - I’m not sure if I enabled it in the past or it was enabled by default.

There could be more users with this problem and unaware. Many users won’t think about checking on fstrim. I didn’t for over a year after installation.

It is enabled. What is purpose of your message? You posted your service status for what?

I also have fstrim disabled. I have LVM on LUKS setup. If I enable it won’t I corrupt data?

The only concern is that when an SSD is trimmed, and you’re using encryption between the file-system (ext4, xfs, btrfs, etc) and the drive (SSD), is that someone who has physical access to your drive can run forensics on it to discern a few things:

  • what type of file-system you were most likely using (through a block device “fingerprint” analysis, not even with 100% certainty)
  • how much used space versus available space on the file system

But honestly, that’s about it. :man_shrugging: If you prefer the performance gains from a weekly fstrim, there’s no harm in enabling it. Make sure to also allow it by changing the default Grub settings:

https://confluence.jaytaala.com/display/TKB/Enable+periodic+TRIM+-+including+on+a+LUKS+partition

I use LUKS + fstrim, and if it comes to a point where someone else has physical access to my drive and is running forensic tools on it to determine what type of file-system I used and how much data I actually saved on it… well… I’ve got bigger problems on my plate than IO performance benchmarks. :wink:

3 Likes

Im on a XFCE install about 3 years old, mine was disabled. Thanks for the heads up

1 Like

My Manjaro KDE install is 8 month old, i also had Trim disabled, but looks like that its activated and working with systemctl enable --now fstrim.timer

sudo systemctl status fstrim.timer showed me this now:

● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
     Active: active (waiting) since Mon 2021-04-05 02:47:00 CEST; 1min 51s ago
    Trigger: Mon 2021-04-05 02:51:34 CEST; 2min 42s left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Apr 05 02:47:00 koboldx-z170 systemd[1]: Started Discard unused blocks once a week.

Thank you for the response.

I’ve set options up as told in the manual you posted and enabled the timer. Everything works fine. I have a question. Is it necessary to set this option in /etc/lvm/lvm.conf?

issue_discards = 1

I don’t believe so, because since LVM v2 trim commands pass through the logical volumes by default. You can test this out yourself:

sudo fstrim -v -a

Wait for the command to finish. Any errors? Or does it output the results, such as:
/: 409.8 GiB (440062459904 bytes) trimmed on /dev/sda1

If all looks well, then the systemd timer and service will take care of the rest. The command you just manually invoked is essentially what fstrim.timer does on a weekly basis. Assuming the timer is active (see earlier in this thread). My above output is just an example, and I’m not using LVM, hence why you see /dev/sda1.

No need to change or add anything if it’s working as expected. :slight_smile:

1 Like

Yes, sudo fstrim -av reports no errors.

Thank you!