recovery mode - If I reset my phone, will it also TRIM the fragmented eMMC?

I know that Android supports fstrim but it only works if the phone is idle for a long time while charging. I think my phone is too fragmented and is lacking performance so I want to reset it but I am not sure if TRIM will also run if I do so. Since TRIM is important to improve the SSD's speed, I'd really like to run TRIM on my phone.

Answer

Android supports fstrim but it only works if the phone is idle for a long time while charging

It's not so. On newer versions, Android runs fstrim with a daily schedule, provided that the conditions meet. Or it should run on a reboot if not run for 3+ days. See this answer for details and how you can run fstrim manually.

FRAGMENTATION ON FLASH MEMORY:

I think my phone is too fragmented and is lacking performance

No, fragmentation doesn't exist on flash memory, or at least doesn't affect the performance. It's actually the filesystem which gets fragmentation (that's why newly formatted filesystem has 0% fragmentation), transferring the same to underlying physical storage. However underlying medium handle it differently.

Let's first take a brief insight into filesystem vs. storage media relationship. Filesystem interacts with Logical Block Addresses (LBAs), which are just numbers representing a unit of memory. Filesystem to LBAs mapping is irrespective of whether underlying media is HDD or SSD.

On HDDs, LBAs to Cylinder-Head-Sectors (CHS; rotating magnetic disks) mapping (1:1 / sequenced / linear) ⁽¹⁾ is created during low-level formatting of disk drive when manufacturing, which never changes except if some sector is marked bad by disk controller firmware (in g-list from disk's defects table) and remapped to some spare sector. OS may also mark sectors bad in filesystem to exclude them for future use, as CHKDSK does on Windows during full format and e2fsck/badblocks do on Linux. So Operating system is aware of the physical geometry of the disk, which is propotional to the geometry of LBAs.

On flash memory (including SSDs, eMMCs, SD Cards and USB sticks etc.), LBAs to Physical Block Addresses (PBAs; silicon cells) mapping is fully controlled by Flash Translation Layer (FTL); a part of memory controller firmware. OS knows nothing about it, it can see at maximum the LBAs, not what's happening below it, not even the ECC of failed memory cells (just like bad sectors on HDD), and that's why we don't realize the bad health of eMMC unless it fails. Since a page of memory can't be just overwritten unlike HDDs, it has to be Erased first before being Programmed (written). A side effect is that a number of pages are erased/re-written and the physical mapping changes even if a small file is edited. On HDDs, files aren't physically replaced unless shortened or elongated. OS is aware of these physical changes on HDD, but not on flash memory.

So on HDDs, OS is aware of the physical fragmentation which is same as filesystem (LBAs) fragmentation, and defragmentation (as done by Windows regularly) occurs at physical level. But on flash memory, you can't simply do defragmentation in actual, rather good flash memory controllers do fragmentation purposely as a wear-leveling strategy. OS has no control over the actual fragmentation at physical level (unless you have some advanced tools to communicate with flash controller). However OS is aware of the fragmentation within filesystem. But if you defragment the filesystem, it won't defragment the flash memory.

Also as @Robert mentioned in comment, there is no effect of physical fragmentation on the performance of flash memory at all because there are no mechanical components in flash memory i.e. no seek latency because of head moving over different tracks as in HDDs. Filesystem fragmentation - as some experts think - may have somewhat impact due to increased number of I/O requests OS has to make to read/write scattered data.

---

Summarizing the above lines:

• On HDDs it's the OS/filesystem which controls where the data is actually saved on physical memory, so it can de-fragment it.


• On flash storage media, OS/filesystem doesn't know where the data is actually saved on physical memory, so it can't de-fragment it.

---

Since TRIM is important to improve the SSD's speed, I'd really like to run TRIM on my phone

When an OS asks a filesystem to send TRIM to eMMC, it actually requests flash memory controller to do Garbage Collection - Erase the PBAs which map to LBAs which belong to deleted files. So the eMMC controller maps those LBAs to already/newly Erased blocks (PBAs). This won't do defragmentation. See above mentioned answer to know how often fstrim should be run.

DOES FACTORY RESET DOES TRIM?

 I want to reset it but I am not sure if TRIM will also run if I do so

Factory reset on Android devices format /data and /cache ⁽²⁾ partitions. So the question is whether formatting is accompanied by TRIM or not.

Well this can't be standardized. Formatting and TRIM are different things, so it depends on the formatting utility whether it sends TRIM command to eMMC or not. Formatting may involve partitioning but in most cases (particularly on Android) it's just the high-level formatting i.e. to create data structures (e.g. superblocks, file tables, directories, inode/block bitmaps, journals etc.) used by the OS to identify the partition's contents.

If we go through the lines in source code of stock recovery which handles formatting of partitions during factory reset, we see no notion of TRIM it does wipe_block_device ⁽³⁾ which calls BLKDISCARD or BLKSECDISCARD provided that they are supported ⁽⁴⁾. Both ioctls are essentially TRIM on block device level (not on filesystem level). fstrim is only run by vold inside the main Android OS. Additionally one of the tools used for creating filesystem mke2fs_static does try to discard device before fs creation ⁽⁵⁾, but not the other tool e2fsdroid_static. So there are chances eMMC will be sent a TRIM/discard request during factory reset, but be aware of the past: Android phones don't completely wipe data when their factory reset option is run.