fstrim bug on encrypted LMDE5

[git70]

Hi

fstrim correctly truncates the /boot partition but does not trimmed the root partition /

Example:

~$ sudo fstrim -a -v
/boot: 591 MiB (619728896 bytes) trimmed on /dev/sda5

systemctl status fstrim and systemctl status fstrim.timer work fine.

On LM19.3 and LM20.3 and pure Debian 11 it works fine:

~$ sudo fstrim -a -v
/boot: 591 MiB (619728896 bytes) trimmed on /dev/sda5
/: 242.6 GiB (260511424512 bytes) trimmed on /dev/mapper/vgmint-root

[Harry-W-Haines-III]

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.

[git70]

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.

[Jeremy7701]

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.

[git70]

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.

[monsta]

Maybe check the differences in /etc/crypttab and /etc/fstab between the distros? I suspect there could be discard option missing in LMDE...

[Jeremy7701]

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.

[monsta]

Ah right... and that's in /etc/fstab. So we need to look in /etc/crypttab.

[monsta]

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:

[git70]

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:

• for some reason you fill the disk almost full
• then you clean up and reduce filling by half
• then automatic fstrim (discard) informs the disk controller about the recovered space

In the above problem (with FDE encryption on) fstrim will never inform the controller which cells can empty :(

[Jeremy7701]

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???

[git70]

1. All my current computers (LM19.3 and LM20.3 and pure Debian 11 - see first post) have pruning on all file systems and this is a default in most distribution.
2. The problem only occurs on LMDE5
3. It's not about frequent startup -> automatic default is 1 per week
4. It is not about leaving an unwashed space and not that SSD cannot use it. The point is that if the trim does not occur, then on the encrypted disk the disk controller will never perform internal maintenance (Garbage Collection), because he will not know which sectors are empty (for him they are encrypted, so they do not touch them).

[git70]

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? .... :(

[monsta]

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.

[git70]

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!

[monsta]

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.

[git70]

Thank you @clefebvre ! Does this mean that installation ISO will be updated now or only for LMDE6?