TRIM vs Discard
Also known as: ssd trim command, discard flash, trim vs discard
TRIM and discard are two names for the same idea: telling flash storage which blocks a deleted file no longer needs, so the controller can erase them ahead of time. 'TRIM' is the SATA/SSD command name; 'discard' is the generic file-system/Linux term that also covers UNMAP on UFS/eMMC.
- TRIM (SATA) and discard (generic/Linux) are the same operation; UFS uses UNMAP and eMMC uses DISCARD/ERASE.
- It tells the flash controller which blocks a deleted file no longer needs, so they can be erased ahead of time.
- Phones run it automatically (often as batched fstrim while idle/charging) — there's no manual TRIM setting.
Why flash needs to be told about deletes
When you delete a file, the file system usually just removes its directory entry and marks the blocks as free — the actual data is left on the device. A hard drive doesn't care, but flash storage does: NAND must be erased in large blocks before it can be rewritten, and the controller can only optimize this if it knows which blocks hold real data versus stale, deleted data.
TRIM (the ATA/SATA command, mirrored by UNMAP on SCSI/UFS and DISCARD on eMMC) is how the OS passes that information down. After a delete, the file system issues a TRIM/discard for the freed logical blocks. The controller can then erase them in the background and keep a pool of ready-to-write pages, which preserves write performance and improves wear leveling over the life of the device.
TRIM vs discard: same job, different names
The terms describe one operation at different layers. TRIM is the protocol-level command on SATA SSDs. Discard is the generic word used by file systems and the Linux block layer for 'this range is no longer in use' — it maps to TRIM, UNMAP, or the eMMC DISCARD/ERASE op depending on the underlying bus. So 'enabling discard' and 'enabling TRIM' mean the same thing in practice.
On phones the work is hidden. Android issues discards for F2FS/ext4 volumes, often batched during idle (fstrim) rather than on every delete, to avoid stalls. iOS with APFS handles equivalent block reclamation automatically. There is no user setting to toggle; the platform decides when to send the commands, typically when the device is charging and idle.
What it means after you clean up
This is why freeing space sometimes seems to 'settle' a little after the fact: deleting large files frees the logical space immediately, but the controller may not physically erase those NAND blocks until the next discard/fstrim pass. The reported free space is accurate right away; the background erase just keeps future writes fast.
For cleanup, the takeaway is simple — actually deleting data (emptying Recently Deleted, clearing app cache, removing duplicate photos and large videos) is what lets TRIM/discard hand those blocks back to the controller. Cleanor surfaces and removes that reclaimable data; the OS then issues the discards on its own schedule, so you don't need to manage TRIM manually.