nvme0n1 259:0 0 931,5G 0 disk
├─nvme0n1p1 259:1 0 500M 0 part /boot
├─nvme0n1p2 259:2 0 431G 0 part /Windows
└─nvme0n1p3 259:3 0 500G 0 part
└─cryptroot 254:0 0 500G 0 crypt /var/cache
/home
/
Linux is installed on cryptroot (btrfs).
In fstab I have noatime option, and I have enabled fstrim.timer
Today after a few disk manipulations I did fstrim -av
There was an information:
/boot: 409.5 MiB (429387776 bytes) trimmed on /dev/nvme0n1p1
/Windows: 405.9 GiB (435814555648 bytes) trimmed on /dev/nvme0n1p2
Nothing trimmed on nvme0n1p3.
I tried to manually trim / but I got and information: fstrim: /: the discard operation is not supported
So is this not possible to trim encrypted partition?
It’s possible to trim encrypted partition but it’s disable by default as it have security implication.
Please take a look at this stackexchange question https://askubuntu.com/questions/115823/trim-on-an-encrypted-ssd
Before doing anything to you disk please backup your disk.
rd.luks.options is irrespective of your boot loader. It applies LUKS options to encrypted devices accessed from the ramdisk (hence the “rd”). It follows the same options/syntax as are used in your cmdline (separated by colons) as well as the crypttab options column.
It does the same thing in terms of allowing trims. You can leave it alone or add it, up to you. If you notice that trims are still not allowed, you can add the above rd.luks.options parameter, reboot, and then check to see if it works now.
If everything is working without it, it’s fine to just leave it alone and only consider adding it in case something isn’t working in the future.
You made a small mistake in the first one. rd.luks.options is its own parameter; it’s not part of the cryptdevice string.
However, your second example is “correct”, but also contains a small typo. You have an extraneous colon at the end of your cryptdevice string, immediately after allow-discards. That extra colon ( : ) should be removed.
I don’t understand? I thought you already added the proper HOOKS in your mkinitcpio.conf file? Otherwise you wouldn’t have been able to successfully boot into your encrypted root partition in the first place.
Yes I did but I thought that:
If I use encrypt hook then I should use allow-discards
And if I use sd-encrypt hook then I should use rd.luks.options=discard
But you said
So I assume that it doesn’t matter what I put into my mkinitcpio (encrypt or sd-encrypt) because it’s not affect boot loader entry
Am I right?
encrypt vs sd-encrypt is a matter of old vs new. sd-encrypt brings with it some additional features (which aren’t game-changing for most users), but that’s really it.
What’s important is the order of your hooks, and if you’re happy with how things work right now.
I personally use the encrypt hook, and I’m satisfied. I don’t need the ability to use a detached LUKS header during bootup, and I doubt you need it either.
With that said, I use both flags in my boot entry, to cover myself in the future just in case one is deprecated down the line. (i.e, rd.luks.options=discard and xxxx…xxxx:allow-discards)
Here’s the ultimate test:
sudo fstrim -va
If your file-systems display the trim results, you’re good to go.
DISCLAIMER: I believe if you decide to use the “sd-” version of certain hooks, then you must use the “sd-” version of other related hooks. I’m not sure how true that is, though, and if it’s only a compatibility issue from the past.
