Bug 19086 - SSD TRIM doesn't work on luks encrypted partitions inside an LVM
Summary: SSD TRIM doesn't work on luks encrypted partitions inside an LVM
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
URL:
Whiteboard:
Keywords: 6sta1
Depends on:
Blocks:
 
Reported: 2016-07-29 07:03 CEST by Pete Dan
Modified: 2020-07-04 17:45 CEST (History)
7 users (show)

See Also:
Source RPM: util-linux
CVE:
Status comment:


Attachments

Description Pete Dan 2016-07-29 07:03:24 CEST
Running fstrim on encrypted partitions inside an LVM using etx4 and luks gives a message that "the discard operation is not supported".

Steps to Reproduce:

1. Edit /etc/lvm/lvm.conf to set "issue_discards = 1"
2. Edit /etc/crypttab to add the discard flag (also tried with allow-discards)
3. Run dracut -f -I /etc/crypttab
4. Also tried adding the discard flag in /etc/fstab
5. Reboot
6. As root, run "fstrim -v /", which says that "the discard operation is not supported"

fstrim runs fine on unencrypted partitions on the same disk.

Tried it on Mageia 5 and Mageia 6 sta1

(Additionally tried editing /etc/default/grub, adding the rd.luks.options=discard argument to the end of GRUB_CMDLINE_LINUX and rebuilding the grub config file but result is the same)

This bug means that an encrypted installation on an SSD can't get TRIM to work, which will result in degraded performance after a period of time.
Pete Dan 2016-07-29 09:24:51 CEST

Component: Release (media or process) => RPM Packages

Comment 1 Morgan Leijström 2016-07-29 18:53:14 CEST
Thank you for the investigation.
I am just another user with some interest in this.

Possible workarounds:

1) Have you tried if encrypting the pv instead works?
Anyway, for a secure system you will probably like to have swap and maybe even /etc and possibly other (I used to have /home, /, and swap in an encrypted LVM, and only /boot separately), so put all partitions you want to encrypt in the LVM.

2) instead of continuous trim there is a script that could be run nightly to trim "all at once" preferable when you computer is not much used.  Actually that will make your system have more performance the rest of time as trimming each file deletion makes the drive a bit busy that little time.

CC: (none) => fri

Comment 2 Thierry Vignaud 2016-07-29 20:12:40 CEST
No distro does that automatically AFAIC.
Those instructions are valid for all distros (FC, Debian/Ubuntu, ...)
There's nothing critical there

CC: (none) => thierry.vignaud
Severity: major => normal

Comment 3 Pete Dan 2016-07-30 01:03:51 CEST
(In reply to Morgan Leijström from comment #1)
> Thank you for the investigation.
> I am just another user with some interest in this.
> 
> Possible workarounds:
> 
> 1) Have you tried if encrypting the pv instead works?
> Anyway, for a secure system you will probably like to have swap and maybe
> even /etc and possibly other (I used to have /home, /, and swap in an
> encrypted LVM, and only /boot separately), so put all partitions you want to
> encrypt in the LVM.

So far I have tried with an encrypted LVM setup as you described.

> 2) instead of continuous trim there is a script that could be run nightly to
> trim "all at once" preferable when you computer is not much used.  Actually
> that will make your system have more performance the rest of time as
> trimming each file deletion makes the drive a bit busy that little time.

I believe even running fstrim once per month could be sufficient in most scenarios. Of course, in this case you can't run fstrim at all.
Comment 4 Pete Dan 2016-07-30 01:22:50 CEST
(In reply to Thierry Vignaud from comment #2)
> No distro does that automatically AFAIC.
> Those instructions are valid for all distros (FC, Debian/Ubuntu, ...)
> There's nothing critical there

To add clarity to my original report, this is not a problem of not doing it automatically, but of following those instructions and fstrim still not working.
Comment 5 Marja Van Waes 2016-07-30 19:59:27 CEST
(In reply to Pete Dan from comment #4)
> (In reply to Thierry Vignaud from comment #2)
> > No distro does that automatically AFAIC.
> > Those instructions are valid for all distros (FC, Debian/Ubuntu, ...)
> > There's nothing critical there
> 
> To add clarity to my original report, this is not a problem of not doing it
> automatically, but of following those instructions and fstrim still not
> working.

Assigning to maintainer

Source RPM: (none) => util-linux
Assignee: bugsquad => tmb
CC: (none) => marja11

Comment 6 Florian Hubold 2016-07-31 14:36:52 CEST
FWIW OP added the workaround on the forums thread in https://forums.mageia.org/en/viewtopic.php?p=65451#p65451
which is basically to open the LUKS partition via "cryptsetup luksOpen --allow-discards /dev/sdX some_name" when booted from any live media.

It seems we're not doing this in initrd even when /etc/lvm.conf contains "issue_discards = 1" and /etc/crypttab contains "discard" in the last field (options) and after initrd were recreated, which seems the actual problem for people trying to enable it manually for LVM over LUKS, probably the same for LUKS over LVM though.

CC: (none) => doktor5000

Dave Hodgins 2020-06-28 17:18:33 CEST

CC: (none) => davidwhodgins
Assignee: tmb => kernel

Comment 7 Albert Rayanov 2020-07-04 17:45:31 CEST
(In reply to Florian Hubold from comment #6)
> It seems we're not doing this in initrd

Hello, I face the same problem, Cauldron. I'm ready to give some information, maybe with some debug output if the instruction is given.

CC: (none) => northsoft


Note You need to log in before you can comment on or make changes to this bug.