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@xxxxxxxx > https://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
