Dennis HilkLinux Fix LabDE

Storage & Filesystems

TRIM fails on a filesystem or storage layer

Check discard capability through the complete storage stack when fstrim reports unsupported operation, without confusing reported bytes with freed data.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • A periodic fstrim service reports discard unsupported.
  • The physical SSD supports discard but its mapped device does not advertise it.

Relevant environment

SSDs behind local block devices, LVM, encryption or USB bridges; discard support must reach every relevant layer.

Recognizable messages (synthetic examples)
fstrim: /mnt/usb: the discard operation is not supported

Check filesystem and block-layer capability rather than treating this as a data-integrity failure.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • A bridge, mapping or encryption policy may block discard even when the drive itself supports it.
  • The filesystem or specific mounted target may not support FITRIM; this is not automatically an SSD fault.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read discard advertisement for every visible block layer; no discard command is issued.

lsblk -D -o NAME,TYPE,DISC-GRAN,DISC-MAX,DISC-ZERO,MOUNTPOINTS

Interpret the result: A zero DISC-MAX at the effective filesystem device means discard is not advertised there. DISC-ZERO is not a secure-erasure guarantee.

Check 2

Read the last systemd service result; this does not start trimming. On non-systemd systems inspect the scheduled task’s log instead.

systemctl status fstrim.service --no-pager

Interpret the result: An unsupported target can fail independently of other mounts. The reported trimmed byte count is a range offered to the device, not newly deleted file bytes.

Evidence-guided next steps

Review the layer that blocks discard

If lsblk identifies a mapping layer that blocks an otherwise supported path, review that layer’s documented discard policy and enable passthrough only when appropriate for this storage design. Verify advertisement after the change before scheduling trim.

Precautions: Encrypted-volume discard can reveal allocation patterns. Unsupported USB firmware cannot be fixed by forcing discard; keep backups before mapping changes.

Recovery / rollback: Restore the previous mapping or encryption option and reopen it using the normal maintenance procedure if support or behavior worsens.

Did this solution help you?

Share this solution#

Adjust periodic trim to supported targets

If one filesystem or bridge genuinely lacks FITRIM support, omit that target using the scheduler’s documented selection while keeping eligible SSD mounts in the periodic job. Review an alternative bridge only if discard is a real requirement.

Precautions: Do not disable trimming for all SSDs because one mount is unsupported. Avoid claiming that periodic trim recovers filesystem free space or securely erases files.

Recovery / rollback: Restore the prior scheduler target selection from its saved configuration if a supported filesystem was accidentally omitted.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.