3

Based on this cyanogenmod forum thread, I tried to address the delay in running applications and switching between applications on my Galaxy Nexus running cyanogenmod with Android 4.4.4 by running fstrim manually.

root@maguro:/ # fstrim -v /data                                                          
/data: 11649122304 bytes trimmed                                                         
root@maguro:/ # fstrim -v /cache                                                         
/cache: 436121600 bytes trimmed                                                          
root@maguro:/ # fstrim -v /system                                                        
/system: 80490496 bytes trimmed
root@maguro:/ # exit

This has largely fixed the delay issues. The delay to return to the home screen, for example, has reduced from about 4 seconds to less than 1 second. Based on this performance boost, I expect the delay was caused by the filesystem running inefficiently.

Isn't the Android OS supposed to run fstrim on its own? When is this supposed to happen?

  • Does this article help you? It discusses stock ROMs. I don't know whether or not it applies to CyanogenMod. – unforgettableid Dec 4 '15 at 17:46
  • @unforgettableid Please post as an answer. – mattm Dec 4 '15 at 19:08
4

Unforgettableid's comment included an AnandTech article that describes the conditions under which fstrim is supposed to run:

I’ve learned a bit more on the conditions underlying when Android 4.3 will TRIM filesystems, as it wasn’t completely clear before. The Android framework will send out a “start idle maintenance window” event that the MountService listens for, and then invokes vold to fstrim filesystems when a few conditions have been met – the device hasn’t been touched for over an hour, no idle maintenance window event has been sent in 24 hours, and the device is either off-charger with 80% battery or on-charger with 30% battery. The goal is to have fstrim run roughly once every 24 hours if you’re in the habit of plugging the device in to charge every night.

3

The article referenced in @mattm's answer is a bit outdated. IdleMaintenanceService was removed in Lollipop, things have changed. On Pie, scheduled fstrim is triggered from StorageManagerService (1) to MountService (2):

if the device is alive at midnight + idle, fstrim gets run at the next available charging + idle time

* (3)
Mount service calls StorageManager which in turn calls Vold to do fstrim.

If the schedule is being missed because the conditions don't meet and fstrim has not run for last 3 days (4), it will be forced during device startup if the device is restarted. SystemServer (5), PackageManager (6), StorageManager (7) and Vold (8) are involved.

In each case, the file /data/system/last-fstrim (9) (since Lollipop) gets updated (10), so you can check its timestamp (requires root) to find out when fstrim was last run.

If you want to do TRIM manually, use Android's commandline tool sm fstrim (requires root or adb shell). Previously this was vdc fstrim dotrim but added to Storage Manager in Oreo (11) and removed from vold in Pie (12).

In order to send FITRIM ioctl to selected filesystem(s) only, use fstrim tool (requires root); a busybox applet.


What if you don't have root?
And you suspect that the scheduled fstrim is being missed for 3+ days, restart device, fstrim will be forced (since Lollipop 5.1 (13)). Simple.

Apps can't TRIM without root; see this answer.


HOW OFTEN TRIM SHOULD BE RUN?

Flash memory (including SSDs, eMMCs, SD Cards, USB sticks etc.) has limited number of Program/Erase cycles before it dies. But unlike HDDs, data can't be just overwritten on flash memory, it has to be Erased first, which is achieved through Garbage Collection.

Now if we do too much fstrim, this will cause frequent GC in background consuming precious P/E cycles and hence reducing life. If we don't do fstrim at all, there could be unnecessary GC (of already deleted data), plus the write operations will get too slow with time because Erase will have to be performed before overwriting data, which has very higher latency as compared to Program operation.

So we need a balance between both.

Also there are other factors e.g. whether eMMC controller supports over provisioning, how effective it is in background GC scheduling, wear-leveling and managing write amplification etc.

So unless you have the data sheet of your phone's eMMC and you are sure what you are doing, better is to leave the fstrim to OS. On PCs' (14):

Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices. For most desktop and server systems a sufficient trimming frequency is once a week.

But this may vary with situations.

RELATED:

1

Answer by mattm indicates conditions under which, fstrim should run. I am not aware if the behaviour has changed in subsequent Android versions, but I came across an app that does fstrim on demand as also on reboot . Root needed. Sharing this information as it may be useful to those who are not Linux savvy ( like me :)

SSD Boost

Android 4.3+ supports trim natively, it means that operating system after deleting a file will sends a trim command to nand controller notifying witch blocks the file used, the controller will erase them when idle so it can write fast without erasing next time.

But users have no control over this process and Android doesn't trim the storage for a very long time.

'SSD Boost' helps you to run trim on your device manually if you feel it has become laggy and anyway it does trim for you on every reboot.

I know this directly doesn't answer the question, but felt this was the best question on site to share this

  • I did feel an improvement in terms of reducing lagging as claimed by the app but that could well be a placebo effect – beeshyams Jul 15 '17 at 9:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.