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

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

[Mistave]

Hello!

I have some questions about the TRIM/discard for LUKS-encrypted SSDs.

I currently have a custom Ubuntu 20.04 LTS setup with encrypted ext4
rootfs partition (it's /dev/sda2 and /dev/sda1 is the EFI partition) on
an HDD that I'd like to migrate to an SSD. I was originally going to do
a block-for-block copy using dd, but I figured it'd be better and faster
to copy just the files from rootfs and the EFI partition rather than the
entire disk. So I'm going to setup a new LUKS volume (same parameters)
on the SSD and then sync the filesystem contents over there.

This got me thinking about optimizing the system for SSD since it was
originally installed on an HDD. While googling for information I found
out about two types of TRIM: continuous and periodic. The docs say that
the continuous mode is activated by adding a "discard" parameter to the
rootfs mount options in /etc/fstab or by activating a certain flag by
tune2fs. The periodic mode is activated by placing the fstrim utility on
a timer i.e. a weekly cron job or systemd timer. I noticed the latter is
already active on my system.

Anyway, I was wondering how this is handled when dm-crypt lies between
the SSD and the filesystem. Do I need to take any additional steps in
this case or will fstrim do its thing as is? I'm just checking because
there is so much contradicting information available online. Some people
mentioned that a "discard" parameter should be added to /etc/crypttab
entry, others claim they must be present on both files - fstab and
crypttab. Some even suggest to add an "allow-discards" parameter to the
GRUB kernel command line in /etc/default/grub file. I was also told that
the continuous TRIM is discouraged and that periodic should be used instead.

What's the correct thing to do here?

Thanks in advance.
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
https://www.saout.de/mailman/listinfo/dm-crypt

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

[Martin Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1742 bytes --]

On Sun, Dec 20, 2020 at 12:47 PM Mistave <mistave@countermail.com> wrote:

> Hello!

...

> there is so much contradicting information available online. Some people
> mentioned that a "discard" parameter should be added to /etc/crypttab
> entry, others claim they must be present on both files - fstab and
> crypttab. Some even suggest to add an "allow-discards" parameter to the
> GRUB kernel command line in /etc/default/grub file. I was also told that
> the continuous TRIM is discouraged and that periodic should be used
> instead.
>
> What's the correct thing to do here?
>

There's a longer explanation e.g. here:
https://stackoverflow.com/questions/61428311/ssd-trim-on-linux and I
understand that LUKS does not allow TRIM by befault, because of security
issues:

*"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."*

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


Br,

M.

[-- Attachment #1.2: Type: text/html, Size: 2518 bytes --]

[-- Attachment #2: Type: text/plain, Size: 135 bytes --]

_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
https://www.saout.de/mailman/listinfo/dm-crypt

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

[Mistave]

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


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

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

[Mistave]

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