Re: [dm-crypt] Properly enabling TRIM for dm-crypt on an SSD

[Mistave <mistave@countermail.com>]

On 2020-12-21 17:53, Mistave wrote:
>
> 
> On 2020-12-20 19:12, Martin Jørgensen wrote:
>> *"Note that if you're using LVM or cryptsetup, all such layers need to be
>> configured to pass through the discard operation to the lower layer. By
>> default, cryptsetup ignores discard operations as it prioritizes privacy
>> over performance – TRIM by its nature reveals which disk areas are in use
>> and which ones are free."*
> 
> So, if I understand correctly, this means that even though the fstrim
> utility runs every once in a while and sends TRIM commands down the
> pipe, they will be caught and stopped by the dm-crypt layer unless it is
> also configured to let them pass.
> 
> In this case the only thing I need to do is activate TRIM on dm-crypt
> since I don't use LVM.
> 
> 
>> For the last part I now think I understand the need for passing through
>> discard operations to the lower layer (haven't done it but also haven't had
>> problems in years using LUKS). I think something like this could be what
>> you're looking for:
>> https://blog.christophersmart.com/2013/06/05/trim-on-lvm-on-luks-on-ssd/ -
>> I found several similar posts on google, it seems you basically need to
>> ensure that discards are sent to the crypto layer by adding the
>> *allow-discards* option to /etc/crypttab... Haven't actually done it myself
>> - maybe I should do that in near future, sounds like a good idea...
> 
> The /etc/crypttab should use the keyword "discard" according to debian
> documentation. I believe that "allow-discards" is meant to be a kernel
> parameter passed by the bootloader. I've also seen
> "rd.luks.allow-discards" or "rd.luks.options=discard" used on some
> pages. We'll see, if any work for me.
> 
> To test, I'm going to use the following command:
> # dmsetup table | grep allow_discards
> 

UPDATE: Yes, it works!
I've added both, the "allow-discards" to the kernel command line as well
as specified the "discard" option in /etc/crypttab. The "dmsetup table"
now shows rootfs mounted with allow_discards option.

Also, note to self and everyone else:
I recreated a new guid parttable on the SSD, placed a new LUKS volume on
the main partition, put ext4 on top and rsync-ed the whole rootfs from
the old HDD. This will naturally mean you will have to adapt the
mountpoint names accordingly in i.e. /etc/fstab (/ and /boot/efi),
/etc/crypttab, /etc/default/grub, /boot/efi/EFI/ubuntu/grub.cfg and
/boot/grub/grub.cfg (use grub-mkconfig for the latter). Remember to also
run "update-initramfs -u -k all" afterwards.

Final note:
When chroot-ing into your new LUKS partition be sure to give the
dm-crypt device the exact same name as in the old setup. For example, I
originally named it "cryptroot", but when I was editing the config files
on the SSD I incidentally named it "ssd" i.e. "cryptsetup open /dev/sda2
ssd". I then mounted sys, proc, dev, pts, efi and finally chrooted into
it. This unfortunately caused the booting to abort because although the
update-initramfs created the images, it failed to recognize the rootfs
and put an empty crypttab into the image.



> Kind regards,
> M.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt
>
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
https://www.saout.de/mailman/listinfo/dm-crypt