TRIM on encrypted SSDs

Enable TRIM on supported SSD and NVMe storage, including encrypted root filesystems, for ordinary personal and business privacy needs. On heavily used drives, the performance and responsiveness benefits can be huge. Our operational experience also includes a major stability improvement after combining a firmware upgrade with TRIM: firmware alone still crashed, while the combination appears to have stopped the crashes.

For a normal, non-military privacy situation, allowing the SSD to reclaim unused storage is the recommended tradeoff. Keep disk encryption enabled. If concealing which disk regions are occupied is itself a requirement, evaluate that requirement before enabling discard.

Why it matters

Deleting a file frees space in the filesystem. Without TRIM, the SSD may still treat the old contents as data it must preserve. TRIM tells the drive which logical blocks are no longer needed, giving its garbage collector more room to reclaim flash efficiently. This helps sustain write performance as the drive fills and is reused. See Kingston's explanation of garbage collection and TRIM.

The practical benefit goes beyond peak transfer speed: more consistent I/O latency means a more responsive desktop, builds and services under storage load. Reducing unnecessary internal copying can also reduce flash wear. Red Hat recommends batch or periodic discard for supported filesystems and devices.

Our storage troubleshooting found that an NVMe could report zero SMART media errors while still suffering seconds-long I/O stalls. Updating its firmware improved measured latency, but crashes continued. After TRIM was also performed, the crashes appear to have stopped according to subsequent operation. The successful observed combination was firmware plus TRIM; firmware alone was insufficient. This is operational experience rather than a controlled comparison, so it does not establish TRIM as a universal fix for controller failures or crashes.

The privacy tradeoff

TRIM through dm-crypt leaves file contents encrypted, but can expose allocation patterns: an observer inspecting the encrypted device may be able to infer unused regions, approximate space usage or filesystem characteristics. The kernel documents this metadata exposure and disables discard passthrough by default.

For ordinary protection of stored files on a lost or stolen computer, we recommend enabling TRIM and accepting this exposure. Military, classified or other sensitive situations that require hiding allocation patterns need a separate assessment. The relevant question is whether that metadata must remain hidden, rather than whether encryption should be disabled.

Diagnose unsupported discard

Run these commands as root:

findmnt -no SOURCE,FSTYPE,OPTIONS /
lsblk -D -o NAME,TYPE,FSTYPE,MOUNTPOINTS,DISC-GRAN,DISC-MAX

A typical encrypted installation has this stack:

NVMe disk → partition → LUKS / dm-crypt → XFS mounted at /

If the disk and partition show a nonzero DISC-MAX, but the crypt mapping shows 0B, the encryption layer is blocking discard. For example:

NAME        TYPE   DISC-MAX
nvme0n1     disk         2T
└─nvme0n1p2 part         2T
  └─root    crypt        0B

That explains this error even though the NVMe itself supports TRIM:

fstrim: /: the discard operation is not supported

Running fstrim without a mountpoint produces no mountpoint specified. Use the mounted filesystem path, such as /, rather than its block device.

Enable discard on LUKS2

First identify the mapper name from findmnt and inspect it:

cryptsetup status root

The following example assumes / is on /dev/mapper/root and the reported type is LUKS2. Substitute the actual name, such as rootfs, if different.

cryptsetup --allow-discards --persistent refresh root

The command may request the LUKS passphrase. It updates the active mapping without unmounting / or rebooting, and stores the discard flag in the LUKS2 metadata for future unlocks. This persistence does not require an /etc/crypttab entry or an initrd rebuild with Ironforge's normal cryptsetup luksOpen boot path. See the cryptsetup refresh documentation.

If the mapping uses custom cryptsetup performance flags, preserve those flags in the refresh command too: refresh can reset omitted optional parameters, and --persistent stores the selected set. The persistence option described here requires LUKS2.

After a successful refresh, verify support and trim the filesystem:

cryptsetup status root
lsblk -D -o NAME,TYPE,DISC-GRAN,DISC-MAX
fstrim -v /

The mapping should now show discard enabled and a nonzero DISC-MAX. fstrim should report a byte count instead of an unsupported-operation error. Recheck after the next normal reboot to confirm the boot path honors the saved setting.

Keep trimming regularly

Allowing discard through encryption does not schedule TRIM. Run fstrim -v / periodically; weekly is a reasonable starting point for an ordinary desktop. Use the machine's configured scheduler, and retain failures in its logs. Ironforge uses dinit rather than systemd, so instructions for systemctl enable fstrim.timer do not apply.

Periodic fstrim works without the XFS discard mount option. Start with batch trimming during a quiet period; continuous discard has different latency characteristics. The reported bytes are ranges submitted for discard, not extra filesystem capacity or a measured speedup.

Bcache needs a separate check

On a filesystem backed by bcache, distinguish filesystem discard through dm-crypt from the cache SSD's own reclamation. Bcache maps logical blocks to cache buckets, so successful fstrim / does not by itself prove that freed cache buckets are being trimmed on the NVMe.

Inspect the cache device's own discard setting and the complete device stack before changing cache policy. Enable cache reclamation through bcache's supported allocator controls for the installed kernel. Do not use blkdiscard on a live cache partition: it can destroy cache metadata and data, including dirty writes that have not reached the backing disk. See the Linux bcache documentation.

If timeouts or crashes continue, investigate firmware, kernel logs and device latency as well as TRIM. Healthy SMART counters alone do not rule out storage stalls.