TRIM and UNMAP: Why SSDs Slow Down Behind RAID Controllers
An all-flash array that was fast when it was built and is noticeably slower a year later, with no change in workload and no failing drive, is a familiar complaint. The usual cause is that the drives no longer know which blocks are free, because nothing is telling them.
This guide explains what TRIM and UNMAP do, why a RAID controller sitting between the filesystem and the drives can break that chain, how the slowdown presents, and what to do about it on an existing array.
Why flash needs to be told
A hard drive overwrites in place. Flash cannot. NAND is written in pages and erased only in much larger blocks, so before a page can be rewritten its whole block must be erased first.
When you delete a file, the filesystem marks the space free in its own metadata and normally says nothing to the drive. From the drive's point of view those blocks still hold valid data it must preserve. It carries them through every garbage collection cycle, copying data nobody wants.
TRIM, and its SCSI equivalent UNMAP, is the message that says these blocks are no longer in use. The drive can then erase them in the background and keep a pool of ready-to-write blocks available.
Without that message the pool shrinks. The drive ends up performing read-modify-erase-write cycles inline with your writes instead of ahead of them, and latency climbs. Our guide on SSD over-provisioning covers the spare area that buffers this, and SSD endurance covers the write amplification it causes.
Where hardware RAID breaks the chain
The message has to travel from the filesystem, through the volume manager, through the RAID controller, to the drive. Every layer must support and pass it on.
The RAID controller is the layer that most often does not. Support varies by controller generation, firmware version, and RAID level, and on parity arrays it is harder because freeing a block changes the stripe the parity was calculated across. Many controllers support it on RAID 0 and RAID 1 but not on RAID 5 or RAID 6, and older controllers may not support it at all.
The result is a stack where the filesystem is issuing discards correctly and they are being silently dropped in the middle. Nothing errors, and there is no warning that the array is running without it.
HBAs in IT mode pass commands through, which is one reason ZFS, Storage Spaces and similar platforms handle flash well. Our guide on RAID controller versus HBA in IT mode covers the trade-off.
How the slowdown presents
It arrives gradually. A new array has plenty of erased blocks, so there is no symptom at first. The problem appears once enough data has been written and deleted to consume the free pool, which can take months.
Writes degrade before reads. Read latency stays reasonable while write latency climbs, so the workloads that notice first are databases, virtualisation hosts and anything write-heavy.
Sustained writes suffer more than bursts. A short burst is absorbed by whatever free blocks remain; a long write run runs out and hits the erase penalty directly.
The drives report healthy throughout. Wear indicators look fine, no errors are logged, the array is optimal. Only latency changes, which is why this gets blamed on the application, the network and the hypervisor before anyone looks at the storage layer. Our guide on measuring storage performance covers taking the baseline that makes this visible.
Checking whether you have it
Start with the controller's documentation for your specific firmware and RAID level, not the general product page. This is exactly the kind of capability that changes between firmware revisions.
Check the operating system is issuing discards. On Linux this is either the discard mount option or a periodic fstrim, and the periodic approach is generally preferred for arrays because it batches the work. On Windows it depends on the volume being recognised as flash-backed, which a RAID controller can obscure by presenting the virtual disk generically.
Check the hypervisor layer too. A guest filesystem issuing discards does nothing unless the virtual disk format and the hypervisor pass them down, and thin-provisioned virtual disks have their own reclaim behaviour on top.
Then measure. A sustained write test on a fresh volume versus the same test on the aged one tells you more than any documentation.
What to do if you do not have it
Over-provision deliberately. The most effective fix on an array that cannot pass discards is to leave a portion of each drive unallocated. Blocks that were never written to are known-free, so the drive keeps a working pool regardless of what the filesystem is doing. Setting aside a meaningful percentage at creation costs capacity and buys back sustained write performance.
Choose write-intensive drives where the workload justifies it, since they ship with more factory spare area for the same reason.
Consider whether hardware RAID is the right layer at all. For an all-flash pool, an HBA with software-defined storage often gives better flash behaviour than a controller that cannot pass discards. That is a design change rather than a setting, so it belongs in a refresh rather than a Tuesday.
If the array is already degraded in performance, a secure erase or full reformat restores the drives to a known-free state, but it destroys the data and needs a restore. Treat it as a last resort and fix the underlying configuration at the same time, or you will be back. Our guide on data sanitisation covers the erase commands themselves.
When it does not matter
Worth saying plainly: not every flash deployment needs this attention.
A read-mostly array, a boot volume, or a workload that writes far below the drives' capability may never exhaust the free pool and will never show the symptom. The drives' own background garbage collection, working with factory over-provisioning, copes fine.
It matters on write-heavy arrays, on volumes with high churn, and anywhere sustained write latency is part of the service. If you are specifying flash for those, ask the discard question during design rather than discovering the answer a year in. Our guide on enterprise SSD versus HDD covers where flash earns its place to begin with.
Sourcing
We supply enterprise SSDs and hard drives across the major manufacturers, including OEM-badged parts, along with RAID controllers and HBAs. If you are specifying an all-flash array and want the controller and drive endurance class matched to the write workload rather than the capacity target, send us the requirement and we will work through it. Request a bulk quote or email sarah.jane@techsellerusa.com.
Common questions
What do TRIM and UNMAP actually do?
They tell the drive which blocks the filesystem no longer needs. Flash is written in pages but erased in much larger blocks, so a drive that does not know a block is free must preserve it through every garbage collection cycle. With the message, the drive erases those blocks in the background and keeps a pool of ready-to-write blocks available. TRIM is the ATA command; UNMAP is the SCSI equivalent.
Do RAID controllers pass TRIM through?
It varies by controller generation, firmware version and RAID level, and this is the layer that most often breaks the chain. Parity arrays make it harder, because freeing a block changes the stripe the parity was calculated across, so many controllers support it on RAID 0 and RAID 1 but not RAID 5 or RAID 6. Check the documentation for your specific firmware rather than the general product page.
Why did my SSD array slow down after a year?
A new array has plenty of erased blocks, so there is no symptom at first. Once enough data has been written and deleted to consume that free pool, and nothing has told the drives which blocks are actually free, they start performing erase cycles inline with your writes rather than ahead of them. Write latency climbs while reads stay reasonable, and the drives report perfectly healthy throughout.
What can I do if my controller does not support it?
Over-provision deliberately: leave a portion of each drive unallocated when creating the array. Blocks never written to are known-free, so the drive keeps a working pool regardless of what the filesystem does. It costs capacity and buys back sustained write performance. Choosing write-intensive drives, which ship with more factory spare area, helps for the same reason.
Will reformatting fix an already slow array?
A secure erase or full reformat does restore the drives to a known-free state and the performance with it, but it destroys the data and requires a restore, so treat it as a last resort. More importantly, fix the underlying configuration at the same time by enabling discards if the stack supports them or over-provisioning if it does not. Otherwise the same degradation returns.
Does this affect every SSD deployment?
No. A read-mostly array, a boot volume, or any workload writing well below the drives' capability may never exhaust the free pool and will never show the symptom, because background garbage collection working with factory over-provisioning copes. It matters on write-heavy arrays, high-churn volumes, and anywhere sustained write latency is part of the service you are providing.
If you are specifying an all-flash array, send us the write workload and we will match the controller and drive endurance class rather than just the capacity.
