How to trim luks encrypted device?

My disk layout is:

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

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?

1 Like


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
Before doing anything to you disk please backup your disk.

1 Like

Thank you.

I don’t want to mess something up.
And I’m not sure if I get arch wiki right.

My systemd boot entry looks like this:

options cryptdevice=UUID=0873c55d-c7ec-43b6-9cc7-c8411f7605b6:cryptroot root=/dev/mapper/cryptroot rootflags=subvol=@ rw

Can I just change it to:

options cryptdevice=UUID=0873c55d-c7ec-43b6-9cc7-c8411f7605b6:cryptroot:allow-discards root=/dev/mapper/cryptroot rootflags=subvol=@ rw


You can also add the option rd.luks.options=discard along the same kernel cmdline flags, to cover all bases.

You will then need to make sure the fstrim.timer is enabled and started. (Invoke “start” at least once.)

1 Like

I already enabled fstrim.timer :slight_smile:

But rd.luks is just for sd-crypt hook right?
I use encrypt hook

Or maybe I don’t understand what you mean?

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. :wink:

1 Like

Thank you very much
Just to be sure
Should it look like this:?

options cryptdevice=UUID=0873c55d-c7ec-43b6-9cc7-c8411f7605b6:cryptroot:allow-discards:rd.luks.options=discard root=/dev/mapper/cryptroot rootflags=subvol=@ rw


options cryptdevice=UUID=0873c55d-c7ec-43b6-9cc7-c8411f7605b6:cryptroot:allow-discards: root=/dev/mapper/cryptroot rootflags=subvol=@ rd.luks.options=discard rw

And do I need to add systemd hook to mkinitcpio?

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. :wink:

options cryptdevice=UUID=0873c55d-c7ec-43b6-9cc7-c8411f7605b6:cryptroot:allow-discards root=/dev/mapper/cryptroot rootflags=subvol=@ rd.luks.options=discard rw

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. :wink:

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. :v:

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.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.