Closed git70 closed 2 years ago
On my system I show the following: sudo fstrim -a -v /boot/efi: 432.3 MiB (453316608 bytes) trimmed on /dev/sda1 /: 282.3 GiB (303155515392 bytes) trimmed on /dev/sda2
Could be something about your particular setup.
After the names of your SDA1 and SDA2 devices, I guess you have an ordinary plain installation. The problem applies to FDE encrypted on LVM.
On LMDE4 [no encryption] I wrote a systemd timer + script to run fstrim -av
weekly
The log says:-
/run/timeshift/backup: 23 GiB (24638566400 bytes) trimmed on /dev/sda4
/mnt/backup: 166.2 GiB (178433847296 bytes) trimmed on /dev/sda2
/mnt/music: 7.1 GiB (7626821632 bytes) trimmed on /dev/sda1
/home: 106.1 GiB (113912266752 bytes) trimmed on /dev/sdb4
/mnt/video: 183.2 GiB (196664238080 bytes) trimmed on /dev/sdb5
/boot/efi: 225.9 MiB (236851200 bytes) trimmed on /dev/nvme0n1p1
/mnt/linux: 39.8 GiB (42672103424 bytes) trimmed on /dev/nvme0n1p3
/: 37.8 GiB (40595226624 bytes) trimmed on /dev/nvme0n1p2
So it would appear that only /dev/XXXXX devices are recognised as partitions.
The problem applies ONLY to the system encrypted LUKS during the installation (Full Disk Encryption, do not encrypt Home catalog).
Additionally, as I wrote above: on clean Debian 11 works properly, and if LMDE5 is based on Debian 11, this problem applies only to LMDE.
Maybe check the differences in /etc/crypttab
and /etc/fstab
between the distros? I suspect there could be discard
option missing in LMDE...
If you specify discard
as a mount option, then my understanding is that trim is going to be run at least after each file deletion. This will impact performance.
A weekly trim is usually sufficient.
Ah right... and that's in /etc/fstab
. So we need to look in /etc/crypttab
.
So I found some time to test it myself...
Added discard
option to /etc/crypttab
, so it looked like this:
$ cat /etc/crypttab
# <target name> <source device> <key file> <options>
lvmlmde UUID=57d30a02-66f4-4f0e-a16d-494609b66dfc none luks,discard,tries=3
Updated initramfs:
$ sudo update-initramfs -t -u -k all
Rebooted and ran fstrim:
$ sudo fstrim -a -v
/boot/efi: 282 MiB (295706624 bytes) trimmed on /dev/sda1
/boot: 851.6 MiB (892993536 bytes) trimmed on /dev/sda2
/: 4 GiB (4253310976 bytes) trimmed on /dev/mapper/lvmlmde-root
Well... it works :slightly_smiling_face:
Wow! Great! :) Thank you very much for your help!
I just wonder how to report it to the LMDE Team ... (I don't know if they read here).
In my opinion, this is an important mistake, because in an extreme case the lack of pruning the file system can shorten the life of an SSD.
For example:
In the above problem (with FDE encryption on) fstrim will never inform the controller which cells can empty :(
You don't need to specify trimming on all filesystems.
fstrim [-Aa] [-o offset] [-l length] [-m minimum-size] [-v] mountpoint
[-o offset] [-l length] [-m minimum-size] would all appear to be rather dangerous. See 'man fstrim'
"Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-qual‐
ity SSD devices. For most desktop and server systems a sufficient trimming frequency is once a week.
Note that not all devices support a queued trim, so each trim command incurs a performance penalty on
whatever else might be trying to use the disk at the time".
I wonder what the effect is of leaving unallocated space? I usually leave around 15% - I don't need it for the present and there doesn't seem any reason why a SSD can't make use of it???
Hmm ...
The only question is whether the addition of discard
to /etc /crypttab
will cause pruning after each deletion of the file, or normally once a week? .... :(
As it only makes that device/partition recognizable by fstrim, I think it should work the same as for others.
There's a caveat in man crypttab
for that option though:
discard
Allow using of discards (TRIM) requests for device.
Starting with Debian 10 (Buster), this option is added per default to new
dm-crypt devices by the Debian Installer. If you don't care about leaking
access patterns (filesystem type, used space) and don't have hidden
truecrypt volumes inside this volume, then it should be safe to enable this
option. See the following warning for further information.
WARNING: Assess the specific security risks carefully before enabling this
option. For example, allowing discards on encrypted devices may lead to the
leak of information about the ciphertext device (filesystem type, used space
etc.) if the discarded blocks can be located easily on the device later.
I think I confused the way the discard
option in /etc/fstab
works with /etc/crypttab
.
These are probably two completely different things...
https://opensource.com/article/20/2/trim-solid-state-storage-linux
These safety threats are not important to me. Information leakage that I have a file system and the amount of place occupied is not a threat to me and I prefer to extend my life and reliability of my SSD.
Thanks again for your help!
I agree - SSDs need that maintenance, and the security issue doesn't seem to be so serious. Just posted it for the completeness. Some people might want to avoid it, some wouldn't care.
Thank you @clefebvre ! Does this mean that installation ISO will be updated now or only for LMDE6?
Hi
fstrim correctly truncates the /boot partition but does not trimmed the root partition /
Example:
systemctl status fstrim
andsystemctl status fstrim.timer
work fine.On LM19.3 and LM20.3 and pure Debian 11 it works fine: