Why is ssd trim disabled by default?

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!

I permanently can activate the timer on my system with the command

systemctl enable --now fstrim.timer

So I don’t really see a problem…
But this didn’t happen automatically after the installation. Now I checked my installation log from summer 2020 to see what there was going on. Check it out for yourself:


Target cmd: (“systemctl”, “enable”, “fstrim.timer.service”) output:
Failed to enable unit, unit fstrim.timer.service does not exist.
2020-07-03 - 21:12:20 [2]: void CalamaresPython::warning(const string&)
WARNING:[PYTHON JOB]: “Cannot enable systemd .service fstrim.timer”
2020-07-03 - 21:12:20 [2]: void CalamaresPython::warning(const string&)
WARNING:[PYTHON JOB]: “systemctl enable call in chroot returned error code 1”

I reinstalled Manjaro Gnome today, and it was not enabled. I had to enable it using systemctl enable --now fstrim.timer

It appears the timer is not enabled by default.

That’s fine. Let the user decide. Besides, if you’re using encryption, you might want to understand the implications of using trim before enabling it.

The title: Why is ssd trim disabled by default?

The general answer for general defaults: Solid state drive - ArchWiki

Most SSDs support the ATA_TRIM command for sustained long-term performance and wear-leveling.

Warning: Users need to be certain that their SSD supports TRIM before attempting to use it. Data loss can occur otherwise!

$ man cryptsetup

--allow-discards
              Allow  the  use of discard (TRIM) requests for the device.  This option is only relevant for open action.  This is also not supported for LUKS2 devices with data integrity
              protection.

              WARNING: This command can have a negative security impact because it can make filesystem-level operations visible on the physical device. For example, information  leaking
              filesystem type, used space, etc. may be extractable from the physical device if the discarded blocks can be located later. If in doubt, do not use it.

              A kernel version of 3.1 or later is needed. For earlier kernels, this option is ignored.

Some person here says that “For most users, the benefit of TRIM outweigh those security concerns.” so while on my MJ the encryption is not set to use discard:

$ sudo fstrim -v /
fstrim: /: the discard operation is not supported

and system does not use fstrim:
$ systemctl status fstrim.timer

○ fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; disabled; vendor preset: disabled)
     Active: inactive (dead)

and my system encrypted drive seems to support TRIM (having non zero values DISC-GRAN & DISC-MAX):
$ lsblk --discard

NAME                                          DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1                                              0      512B       2T         0
├─nvme0n1p1                                          0      512B       2T         0
└─nvme0n1p2                                          0      512B       2T         0
  └─luks-a-b-c-d                                     0        0B       0B         0

i think i should use fstrim? But how to do it? The steps should be?

sudo nano /etc/crypttab
replace luks by luks,discard
(is it safe? i do not want non-bootable system)

Then:
$ systemctl enable --now fstrim.timer
?

I have one HDD and one SSD in my laptop. How should I enable the trimm feature only for the SSD?