[bcook]

Regardless of the differences, the Nexus 7 used trim (introduced in Android 4.3) on it's flash-based (SSD also uses flash) solid-state memory and my Nexus 9 does not. The trim "bug" is well known for some Android devices, but now it has died off. I was attempting to guess why.

Another quick Googling seems to say improved garbage collection (in the SSD itself) has lessened the need for fstrim.

Hopefully someone who is knowledgeable will chime in.

[gnoway]

trim is implemented in the controller in that a controller implementing trim is capable of receiving, understanding and acting upon the trim command. It's actually issued higher up in the stack; I've only ever seen it mentioned in the context of an OS issuing the command to the drive if a file on a filesystem on the drive is deleted, or if a utility intended to issue trim against all empty blocks was run.

You're correct in that trim is less necessary if a drive has good garbage collection. I don't know anything about the implementation of either, but I would expect trim to be easier, cheaper and better than GC. It seems like GC would require work to discover/remember things provided as input w/ trim. I've assumed that GC was only implemented by vendors in their controllers because trim wasn't available in the popular OSs yet, and/or because their controllers were already doing most of the work required by GC anyway so it was cheap to implement.

Finally, you can't equate SSDs with the SD or eMMC used in some of the phones/tablets. Yes it's all flash, but an SSD is typically multi-channel with many flash modules, a DRAM cache and a much more sophisticated controller implementing a standard storage interface (AHCI/SATA or SAS or NVMe). eMMC and SD are much simpler, cheaper and slower.

[bcook]

My point was that they are equal from the fstrim perspective.