Enable SSD TRIM

[zsolt-donca]

What do you need?

I did a fresh installation of Omachy v3.0.2 on a laptop with an nvme SSD, and SSD TRIM does not seem to be working out of the box. This can result in poor performance and reduced life of my SSD.

My enhancement request is to enable SSD trimming automatically within in the installer, or maybe following a prompt. I understand that Arch Linux does not enable it by default because it can have theoretical security implications (see wiki), but I think that's pretty far fetched, and it's not just me: I believe that basically all Linux distros enable it out-of-the box for systems with full disk encryption, including Ubuntu.

See my investigation below, including how to enable it.

Following the Arch Wiki on SSD TRIM, I can confirm that by default my encrypted root partition is not supporting TRIM (by having zero in the column DISC-GRAN:

~ ❯ : lsblk --discard
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
zram0              0        4K       2T         0
nvme0n1            0        4K       2T         0
├─nvme0n1p1        0        4K       2T         0
└─nvme0n1p2        0        4K       2T         0
  └─root           0        0B       0B         0

And triggering a manual trimming also confirms this:

~ ❯ : sudo fstrim -av
/boot: 1.5 GiB (1632141312 bytes) trimmed on /dev/nvme0n1p1

The fix is documented in the LUKS2 page:

# cryptsetup --allow-discards --persistent refresh root

It is persistent, and even starts to work immediately (note the 4K value of root and that fstrim reported trimming the root partition):

~ ❯ : lsblk --discard
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
zram0              0        4K       2T         0
nvme0n1            0        4K       2T         0
├─nvme0n1p1        0        4K       2T         0
└─nvme0n1p2        0        4K       2T         0
  └─root           0        4K       2T         0


~ ❯ : sudo fstrim -av
/boot: 1.5 GiB (1632141312 bytes) trimmed on /dev/nvme0n1p1
/: 908.9 GiB (975896055808 bytes) trimmed on /dev/mapper/root

I am not sure what's the best when it comes to how to actually execute the trimming, but I enabled Periodic TRIM):

# systemctl enable fstrim.timer

Another option would be to use asynchronous discarding through a mount option.

[Shashwat-Chauhan]

Can i take this issue

[dhh]

SSD trim is not needed on modern nvmes. So not going to do this setup as a default. But if you'd like to document it for those with vintage hardware, please add it to the discussions under Manual 👍

[dezren39]

Is this accurate? My understanding was modern nvme still require trim but can use continuous trim, discard=async on the partition in fstab. I can't find any documentation saying nvme don't need trim.

Does this also apply to usb nvme drives? I have a framework with a usb expansion card holding omarchy. This isn't legacy hardware. Typically, you need to enable trim on usb ssd's manually.

[DigitalArchon]

I think there is some misunderstanding about modern nvme drives not needing trim. While technically they will function without it, they will still have all the same negative effects of not using it as older drives, like slowing down massively over time and increased wear.

I know there is some discussion about the security implications of using trim on encrypted SSDs, because the wear leveling does technically expose at least some drive use information. But I would say more importantly, not having trim increases other risks, like old LUKS encryption keys not being removed when the password is changed. (More or less what the Arch wiki says).

But in terms of basic good SSD maintenance and best performance, the need for trim is still definitely there.

[dezren39]

@dhh Can this please be reopened?

[n8himmel]

Reopening this with concrete data from a current-gen NVMe.

Hardware: WD PC SN5000S 1TB (PCIe Gen 4, shipped in 2024/2025 laptops — not vintage hardware)

After a fresh Omarchy install with LUKS encryption, TRIM was completely non-functional. Running fstrim returned "discard operation is not supported." The root cause is two things Omarchy doesn't configure by default:

1. :allow-discards missing from the cryptdevice= kernel parameter — without this, dm-crypt blocks all discard/TRIM commands from reaching the SSD
2. fstrim.timer not enabled — no periodic TRIM runs even if the path were open

After fixing both, fstrim reported over 400 GiB of stale blocks the drive controller didn't know were free. On a 1 TB drive, that's nearly half the disk — the controller was treating all of that as occupied data, causing unnecessary write amplification.

The Arch Wiki explicitly recommends TRIM for all SSDs, including NVMe. Internal garbage collection helps, but it cannot replace TRIM because the controller has no way to know which blocks the filesystem considers free unless told via TRIM/DEALLOCATE.

The only legitimate argument against allow-discards on LUKS is the security trade-off (leaking block usage patterns to physical disk forensics). That's worth documenting, but it's a different discussion from whether TRIM is needed — and for most users, the performance and longevity benefits far outweigh that risk.

Suggested default for Omarchy:

• Add :allow-discards to the cryptdevice= parameter in /etc/default/limine
• Enable fstrim.timer

[dhh]

I'd be happy to look at a PR for this.

[EFrMG]

fstrim.timer service is not needed given that discard=async is enabled by default for supported devices on 'newer' kernels.

Since kernel 6.2 the discard=async mount option is automatically enabled on devices that support that.
source

Both achieve the same exact thing, just that one option does it periodically, and the other (already default) does in in batches / semi-real time.

If this shows fluctuating output, then it is enabled, which in my case it is on an SSD:

watch cat /sys/fs/btrfs/*/discard/discard_bytes_saved

If it instead shows different output, it might be up to the timer service which I do not know if it's enabled by default but most probably is, depending on support of the hardware alone.

More sources:
commit for the auto behaviour
TRIM in SSDs; lifespan

[EFrMG]

Apparently, there is need for a :allow-discards flag at the end of the LUKS2 cryptdevice entry, judging by the output of lsblk --discard which shows the maximum alotted size of discarded space as "0B" if it is not set. So, that part is ok; I thought the output of the cat command above was enough given that it points to the UUID of root.

[WGH-]

After fixing both, fstrim reported over 400 GiB of stale blocks the drive controller didn't know were free. On a 1 TB drive, that's nearly half the disk — the controller was treating all of that as occupied data, causing unnecessary write amplification.

Not necessarily true, though. ext4 remembers discarded blocks only since last mount, btrfs never remembers any. So repeated fstrim calls might report already trimmed blocks, or even blocks never touched in entire disk lifetime.

[j-soro]

I hit this on a LUKS Omarchy install and tracked it down. The missing TRIM was real and worth fixing, but on my machine a second dm-crypt setting mattered more. Which could be relevant here because #5332 only covers the first one.

I wanted to contribute with my numbers, hopefully it will be useful.

Problem: the desktop became unresponsive for several seconds at a time whenever
Steam applied a large game patch. Downloading was fine; only patching triggered it.

I tracked it down to two separate causes.

Self-check for anyone reading this: run lsblk -D. If DISC-GRAN is 0 on your
root mapper, no TRIM is reaching your SSD.

---

Cause 1: the SSD had never been TRIMmed

Zero TRIMs in 17.6 TB of writes, because two independent settings combine to
disable it:

1. LUKS blocks discards unless :allow-discards is set — discard_max_bytes on
   /dev/mapper/root was 0
2. Arch ships fstrim.timer disabled

Together they mean an encrypted Arch install never issues a TRIM, but neither are wrong. I believe it's my bad as Arch user to not enable it manually, but since Omarchy is setting up the LUKS install, maybe it's well placed to set the flag, or at least warn the potentially unaware user that they should take the action.

The first fstrim discarded 487.8 GiB. Identical fio job before and after:

sequential 1M write, O_DIRECT QD8	before	after
	92 MB/s	2886 MB/s

(O_DIRECT means no RAM pre-write. QD8 means eight requests at the same time to keep the drive busy)

The drive is rated ~3000 MB/s, so it had degraded to about 3% of spec. Reads were
unaffected the whole time (1105 MB/s from the raw device, 1058 MB/s through
dm-crypt) which is what rules out wear or the crypt layer. SMART was all good:
1% used, 0 errors.

This drive is an older mid-range model, so the degradation here is
probably serious. A newer drive with better garbage collection would
likely degrade less. But the mechanism is the same on any LUKS install, and
@n8himmel's 2024/25 Gen4 drive showed 400+ GiB untrimmed, so it isn't limited to
old hardware.

Throughput was restored, but the freezes continued.

---

Cause 2: dm-crypt's write workqueue

This is what actually froze the desktop.

By default dm-crypt hands every write to a single kernel thread called
dmcrypt_write. Under sustained load that one thread becomes a bottleneck and
everything queues behind it.

While the system was frozen I sampled that thread's state once a second for twelve
seconds. It was in D state (uninterruptible sleep, i.e. stuck waiting on IO)
all 12 times, with 60 operations queued at the encryption layer
(/sys/block/dm-0/inflight showing read=46 write=14).

Fixed with --perf-no_read_workqueue --perf-no_write_workqueue, which encrypt
inline in the calling process instead of handing off to that thread. This is what
@yevshev suggested in review on #5332.

How I measured it: a bulk writer (4 threads writing hard, simulating the patch) running alongside a small write (simulating the desktop). The measurement is how long the small write had to wait each time (this aims to represent the frozen desktop time).

dm-crypt workqueues	bulk throughput	p99	p99.9	worst case
disabled (--perf-no_*_workqueue)	2054 MB/s	86 ms	181 ms	204 ms
enabled (default)	1538 MB/s	518 ms	2802 ms	6647 ms

32× worse tail latency, for 25% less throughput.

Worth noting: with the workqueues enabled, typical latency is actually
better (0.5 ms vs 5.5 ms). But roughly 1 operation in 1000 waits nearly 3 seconds,
and the worst waits 6.6. This fits my experience with the freezes, all good until suddenly the desktop froze for many seconds straight.

(To be clear about the order: this A/B ran on an already-TRIMmed drive. TRIM
restored throughput but the freezes continued — this second change is what stopped
them. Both were needed.)

End result: a 172 GB Steam staging job that I'd previously had to kill now
completes in ~10 minutes at ~280 MB/s sustained read+write, and I watched YouTube
throughout without a single stutter.

One implementation note for whoever picks this up: :allow-discards can be passed
on the kernel command line, but the workqueue flags cannot — the encrypt hook
doesn't accept them there. They have to be written into the LUKS2 header with
cryptsetup --persistent refresh.

---

On kernel 6.2+ auto-enabling discard=async

My machine is on kernel 7.1.4 and discard_max_bytes on the mapper was still
0, with no discard=async in the effective mount options
(rw,relatime,compress=zstd:3,ssd,space_cache=v2).

dm-crypt sits below btrfs, so it drops discards before they ever reach the
device. Whatever the filesystem decides to do, nothing gets through until
:allow-discards is set. It's a prerequisite for the kernel default, not an
alternative to it.

So I'd ask that this not be used as a reason to skip fstrim.timer. My kernel
is newer than 6.2, has async discard support, and still went 17.6 TB without a
single TRIM. On a LUKS system the kernel default cannot save you. Please either
enable fstrim.timer or set discard=async explicitly rather than assuming the
kernel handles it.

---

On PR #5332

It implements the :allow-discards half, but it's currently in merge conflict and
hasn't been updated since 19 July. It also isn't linked from this discussion, so
I suspect people following the problem don't know the fix exists.

Based on the numbers above I'd suggest it also needs the workqueue flags. On my PC those were the actual responsiveness fix, TRIM just helped with throughput.

---

Things I tried that were not the cause

Listing these so nobody repeats them:

• vm.dirty_bytes: I initially thought this was it. Reducing the writeback
  buffer from 10% of RAM (6.3 GB) to 384 MB gave +12% throughput and ~25% better
  latency, but worst case only went 262 ms → 204 ms. Didn't fix the freeze but I kept this change.
• btrfs CoW / chattr +C on the Steam library: nodatacow was slower
  pre-TRIM (66 vs 84 MB/s). Modest benefit post-TRIM, so I left +C on, but it
  was never the problem.
• The dm-crypt cipher: aes-xts benchmarks at 6.4 GB/s here, and raw vs
  encrypted reads differ by only 4%. The problem was with the workqueue as stated above, not with the cipher.

---

What I'd suggest

1. Rebase and merge Enable SSD TRIM for LUKS-encrypted drives #5332: it's the right fix for :allow-discards and it's
   only blocked on merge conflicts.
2. Add the workqueue flags via cryptsetup --persistent refresh (they can't go
   on the kernel cmdline).
3. Don't skip fstrim.timer on the assumption that kernel 6.2+ handles it. It
   doesn't on LUKS, as above.
4. Link Enable SSD TRIM for LUKS-encrypted drives #5332 from this discussion, so people hitting this problem can find it.

Happy to test any of this and report numbers, or to help rebase #5332 if
@stephentaylor-com would rather hand it off.

---

System

Omarchy	3.8.4, installed 2026-04-19
Kernel	7.1.4
CPU / RAM	AMD Ryzen 9 7950X (16c/32t) · 64 GB
Storage	LUKS2 + btrfs (zstd:3)
Drive	XPG SPECTRIX S40G 1TB, Realtek RTS5762, PCIe 3.0 x4 (link verified 8GT/s x4)
Rated	3500 MB/s read / 3000 MB/s write
SMART	1% used, 100% spare, 0 media errors, 17.6 TB written