Interaction between OPAL drives, LUKS and TRIM/discard
neitsab <[email protected]> Fri, 5 Jul 2024 15:34:34 +0200
| Newsgroups | dev.linux.lists.cryptsetup |
|---|---|
| Message-ID | <[email protected]> |
Hi *, I have been trying out the new OPAL support on the root drive for a new Arch Linux install (using a Samsung 980 Pro and --hw-opal-only): to my surprise it worked flawlessly and I could boot from my OPAL-encrypted, LUKS-managed SED. I really wanted to thank you for adding this support to cryptsetup: it's a whole world of improved usability and integration compared with sedutils. After the fact I wanted to add discard support to my LUKS container so I ran: ``` cryptsetup refresh --allow-discards --persistent /dev/nvme0n1p2 root Enter passphrase for /dev/nvme0n1p2: Unsupported parameters on device root. ``` (I can provide the debug output if you tell me whether to send it in the body of a reply, as an attachment or on a paste service) However, fstrim seemed to be working before that: ``` fstrim -v -a /boot/efi : 424,3 MiB (444919808 bytes) trimmed on /dev/nvme0n1p1 / : 1,8 TiB (1995819851776 bytes) trimmed on /dev/mapper/root ``` This made me wonder about the interaction between hardware-only OPAL, LUKS and TRIM/discard. In the hardware-only OPAL encrypted case, I guess there are no barriers to discards being sent to the drive. Is that why --allow-discards is an "unsupported parameter" and fstrim works by default? If so, do you think it's something that could be added to the docs, a bit like there is a warning about incompatibility with --tcrypt-hidden so as to warn users there is no need to try that? Thanks and regards, Bastien