* [dm-crypt] Properly enabling TRIM for dm-crypt on an SSD @ 2020-12-20 11:36 Mistave 2020-12-20 18:12 ` Martin Jørgensen 0 siblings, 1 reply; 4+ messages in thread From: Mistave @ 2020-12-20 11:36 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dm-crypt] Properly enabling TRIM for dm-crypt on an SSD 2020-12-20 11:36 [dm-crypt] Properly enabling TRIM for dm-crypt on an SSD Mistave @ 2020-12-20 18:12 ` Martin Jørgensen 2020-12-21 16:53 ` Mistave 0 siblings, 1 reply; 4+ messages in thread From: Martin Jørgensen @ 2020-12-20 18:12 UTC (permalink / raw) To: Mistave; +Cc: dm-crypt [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dm-crypt] Properly enabling TRIM for dm-crypt on an SSD 2020-12-20 18:12 ` Martin Jørgensen @ 2020-12-21 16:53 ` Mistave 2020-12-21 21:45 ` Mistave 0 siblings, 1 reply; 4+ messages in thread From: Mistave @ 2020-12-21 16:53 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dm-crypt] Properly enabling TRIM for dm-crypt on an SSD 2020-12-21 16:53 ` Mistave @ 2020-12-21 21:45 ` Mistave 0 siblings, 0 replies; 4+ messages in thread From: Mistave @ 2020-12-21 21:45 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-12-21 21:46 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-20 11:36 [dm-crypt] Properly enabling TRIM for dm-crypt on an SSD Mistave 2020-12-20 18:12 ` Martin Jørgensen 2020-12-21 16:53 ` Mistave 2020-12-21 21:45 ` Mistave
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.