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.
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”
…
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!
--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