> Attention also turned to the behaviour of trim on SATA devices supporting
> NCQ: since Trim isn't a queued command, it means that, to send a trim,
> the device has to complete all queued commands then send a trim on its
> own, then allow the tags to build back up. This causes a pause in the
> disk writes which can damage performance.
TRIMS can be aggregated and send after a flush cache command.
In practice TRIMs should be fine after big read or write requests too,
because those cause enough parallelism without command queueing, so
draining the queue during one of such command should give room for
submitting TRIMs afterwards.