How to Verify TRIM Is Reaching SSDs Behind a NAS Controller

Successful fstrim output does not prove TRIM reached each physical SSD. End-to-end verification requires matching filesystem submission with evidence from lower storage layers.

On a NAS, discarded blocks may pass through a filesystem, encryption, LVM, software RAID, a controller driver, and a virtual disk before any SSD sees them. This procedure separates advertised support from observed discard I/O, shows where hardware RAID can hide the path, and avoids destructive testing on a live pool.

What Counts as Proof That TRIM Reached the SSD?

TRIM verification has several levels. A filesystem can accept a FITRIM request, the Linux block layer can issue discard I/O, a driver can complete it, and a controller can still translate, absorb, or reject the command before a member SSD receives it.

The potential discard bytes reported by fstrim describe ranges submitted from the filesystem into the block stack. They do not certify controller forwarding, physical flash erasure, or even that repeated runs represent newly reclaimed space.

Use the strongest wording your lowest observation supports. A block trace can prove that Linux issued discard to a visible device; only target or controller telemetry can extend that claim beyond a hidden RAID boundary. What the SSD does afterward belongs to SSD garbage collection, not to FITRIM output.

Map the Storage Path Before Testing Anything

Start with the mounted dataset or share, then resolve its actual block path. A common chain is filesystem, encrypted mapper, logical volume, software RAID, controller virtual disk, and physical SSD. Your NAS may omit several layers or hide the final members completely.

Record the mount point, filesystem, device tree, controller model, driver, firmware, operating mode, RAID level, and SSD models. The words HBA, JBOD, pass-through, and RAID mode describe presentation choices, but they do not guarantee identical discard behavior across controllers or firmware releases.

Also identify the command family. Linux calls the operation discard; SATA devices commonly receive ATA Data Set Management with TRIM, SCSI storage uses UNMAP, and NVMe uses deallocation semantics. A bridge or controller must translate and forward the relevant operation for the physical device.

Check Advertised Discard Support at Every Visible Layer

Run lsblk -D and follow the device tree from the mounted filesystem toward the lowest device Linux exposes. Nonzero DISC-GRAN and DISC-MAX values mean that layer advertises discard capability; zero values identify a layer where support is absent or hidden.

The Linux discard queue limits define zero granularity or maximum as no advertised discard support. Check the corresponding /sys/block/DEVICE/queue/ values instead of reading only the top-level virtual disk.

Mapper settings can still suppress pass-through. A practical guide to TRIM through the storage stack shows checks for device-mapper tables and discard limits. Treat nonzero values as permission to continue testing, not as proof that a command reached a member SSD.

Generate a Controlled Discard and Trace the Lowest Visible Device

Use a disposable test allocation inside a healthy mounted filesystem, not a raw sector range. Ensure the allocation is committed, delete it, synchronize the filesystem, and run one targeted fstrim while tracing the relevant block devices. Avoid testing during rebuilds, scrubs, degraded states, or heavy writes.

A focused procedure for auditing discard pass-through uses device statistics and blktrace to distinguish discard events from writes. Verify command fields against the tools installed on your NAS, because trace output and field positions can vary by version.

1. Resolve the mount point to every OS-visible backing device.
2. Capture discard counters and current queue capabilities.
3. Start a discard-filtered trace on the lowest relevant device.
4. Create, commit, and remove a disposable test allocation.
5. Run one fstrim against that mount point.
6. Stop the trace and compare events at each layer.

A discard issue on an upper mapper or RAID node proves only that the request reached that node. A discard issue on the lowest visible member is stronger. Driver completion shows that Linux received completion, but it still cannot reveal hidden controller-to-drive traffic.

Know Where Proof Stops Behind Hardware RAID

A hardware RAID controller may present one virtual disk while keeping member SSDs and their command streams invisible to Linux. In that layout, block tracing can reach the controller driver boundary but cannot establish which physical SSD received TRIM, UNMAP, or a translated equivalent.

A tested example of SSDs behind RAID controllers showed zero advertised discard capability in RAID mode for the examined controller and different exposure in JBOD mode. Treat that as a model-specific diagnostic pattern, not a rule for every controller.

Extend the proof only with trustworthy controller logs, target provisioning status, protocol traces, or documented physical-drive counters. SMART data has no universal TRIM-receipt counter. If the controller exposes no suitable telemetry, the honest result is “discard reached the controller-facing device; physical receipt is unverified.”

Interpret the Result Without Overclaiming

Use the lowest confirmed observation to choose the next action. The table separates capability, observed traffic, and physical receipt so that a clean fstrim result cannot silently become a stronger claim than the evidence supports.

A pass applies only to the tested filesystem, stack, controller mode, firmware, and SSD model. Recheck after a controller update, RAID migration, encryption change, or storage-layout rebuild because any altered layer can change discard exposure or translation.

Do Not Turn Verification Into Data Loss

Do not run raw discard commands against a live NAS pool. The blkdiscard data-loss boundary is explicit: the command discards blocks in the selected range, and its force option can bypass exclusive-access protection.

Do not rely on reading zeroes afterward. Linux documents that post-discard read behavior varies and may be unreliable even when a device advertises zero-return behavior. A controller can also emulate the result without exposing physical NAND handling.

If physical confirmation is mandatory, use an isolated disposable SSD or scratch logical unit with tested backups and controller-specific instructions. For a production NAS, the safe conclusion is often scoped: prove discard to the lowest observable boundary, document what remains hidden, and never risk the pool merely to turn “unverified” into “yes.”