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