Finally Google, you hear us out! Thanks.
Great review from anandtech as always: #fstrim #trim #vold #android #nexus
http://www.anandtech.com/show/7185/android-43-update-brings-trim-to-all-nexus-devices
I really wish Google will also implement the Moto X's Flash Friendly File System aka f2fs on next version of Android to improve random write IOPS and overall system responsiveness.
http://www.anandtech.com/show/7235/moto-x-review/9
-------------
Dear All,
I've been curious after reading Anandtech articles regarding Asus Nexus 7 storage performance and how it compared to other Asus Tablet and Galaxy Nexus. Using Androbench app from Google Play as their tool, I managed to get the result of my Galaxy Nexus after it being used to watch tv series this last three week, and to my surprise, the performance was slowed down perhaps because all the capacity has been used and overwritten and thus having this write amplification effect on flash memory and ssd.
I don't know how to TRIM a eMMC storage on Galaxy Nexus, neither have the knowledge of app or tweak to TRIM, thus I reset to factory image since it formated six partition and restore each to a clean slate with the bootloader, radio, system, userdata, boot, and recovery images. So here's the result I found as per attached. The results were quite shocking though not so significant but it seemed the flashing of the images did restore the storage performance back to normal.
Now I wonder if Linux kernel on Android Jelly Bean supports or will support automatic trimming the eMMC in the near future so it will restore the eMMC (storage) write performance when idling, or is there a tool or adb command to trigger the TRIM command so we don't have to do the backup and restore when resetting to Google factory image?
Resources:
- Anandtech: Exploring the Relationship Between Spare Area and Performance Consistency in Modern SSDs
- Anandtech: Asus Nexus 7 Storage Performance
- Anandtech: SSD Anthology
- Anandtech: Performance Over Time and TRIM
- Wikipedia: TRIM
- Debian Linux SSD Optimization
- Impact of ext4′s discard option on my SSD
- Android on eMMC: Optimizing for Performance
- LINARO: Intro to eMMC - Effectiveness of TRIM
I found bug reported on Android Open Source Project with Issues ID 37258. The screenshots of their Androbench app results were scary, reach below 1Mbps for sequential write (recall the USB1.1 performance?).
Please vote for this issues if you're having similar slow down experience after using your sdcard's capacity to the max. There are already more than 200 people vote for this issue. The more people vote the more chance AOSP developer would hear us out. To vote, click the star icon below add comment section on bottom of this following Android Open Source Issues page:
- Nexus 7 Poor Write Speeds After Using Almost All Storage Capacity
- Galaxy Nexus GSM Poor Write Speeds After Using Almost All Storage Capacity
- Galaxy Nexus Storage Performance Over Time & TRIM
Current work around:
-
- use AuxLV's LagFix (fstrim) app from Google Play weekly. (highly recommended) :good:
- use backfromthestorm fstrim init.d to fstrim on each reboot flashed using CWM recovery, no crontab yet, but much appreciated. (highly recommended) :good:
- use your storage wisely, keeping your free space available at 25% available or more to avoid significant slow write degradation. (highly recommended) :good:
- return to stock or format /system, /data/, and /cache could help your eMMC storage performance back to normal. (recommended)
- mounting the /data partition with discard option and secured erase the free space. (proceed with CAUTION since there's bug brick on some eMMC chip, you may want to check your eMMC chip first using "Got Brickbug ?" app by Chainfire.)
- using kernel with fsync off. (NOT recommended)
Keeping your storage at 25% available will make the storage sub-system performance more consistent on SSD, I believe eMMC using same NAND chipset as in SSD less the controller.
Galaxy Nexus eMMC chip list:
- VYL00M (insignificant effect)
- V3U00M (significant effect)
My take on Galaxy Nexus 16GB storage performance (eMMC VYL00M rev. 0x25):
Return to stock factory image and filling up the storage with 4GB space available:
- SW from 7.53MBps to 5.46MBps ~ 27% loss
- RW from 0.24MBps to 0.22MBps ~ 8% loss
Before and after filling up to 389MB space available:
- SW from 7.53MBps to 3.91MBps ~ 48% loss
- RW from 0.24MBps to 0.23MBps ~ 4% loss
Delete some files to make 4GB space available, and reboot:
- SW from 3.91MBps to 6.96MBps ~ 78% gain
- RW is the same on 0.23MBps ~ no gain/loss
My take on Nexus 4 16GB storage performance:
Before and after filling up the storage (coming from 5GB and filling it up to 1.2GB space available):
- SW from 10 MBps to 4 MBps ~ 60% loss
- RW from 1 MBps to 0.39 MBps ~ 61% loss
Did a reboot and the performance is getting better (1.2GB space available, deleted some files left with 2.2GB space available but the performance is more less the same):
- SW from 4 MBps to 9.89 MBps ~ 147% gain
- RW from 0.39 MBps to 0.51 MBps ~ 31% gain
Using the fstrim app (LagFix for Nexus 7 and HTC One X) and reboot (2.2GB space available):
- SW from 9.89 MBps to 9.9 MBps ~ 0.1% gain
- RW from 0.51 MBps to 1.07 MBps ~ 110% gain
I attached the cwm packages just for backups. Original scripts are written by backfromthestorm. :good:
Credits (notify me if I forgot to add you here):
- ph4zrd
- AuxLV
- backfromthestrom
- JPBeard21
- markop90
- alangrig
- BrianDigital
---
quick thought on samsung eMMC brick bug and how fstrim prolong nand chipset lifespan:
the eMMC brick bug on samsung devices might be related with its own ssd department too. more info about this firmware bug in anandtech site here.
me myself often wonder how come almost all review sites told us to trim in order to prolong the nand chipset lifespan and improve performance. i think i finally found a link to confirm that trim/fstrim does improve nand chipset lifespan by reducing the write amplification.
- without trim: storage is nearly full (used, free, and mark as deleted block), and you need to write a bunch of new files which exceed the free available block, the system must do this cycle: read the mark as deleted blocks, erase the mark as deleted blocks, modify the free available block, and write the new files.
- with trim: storage is nearly full (used, trully free available), and you need to write a bunch of new files, the system just do this cycle: write the new files, hence less write amplification, longer lifespan and much faster write performance.
the trim command and secure erase are somehow very well explained in this write amplification article on wikipedia here.
resources:
- http://www.anandtech.com/show/6503/second-update-on-samsung-ssd-840840-pro-failures
- http://en.wikipedia.org/wiki/TRIM
---
Factory reset via stock recovery, and then use LagFix app or cwm flashable fstrim for optimizing io performance:
AuxLV has made this wonderful app to fstrim your NAND/eMMC storage so it will restore the write performance back to normal after having slow down issues on sequential write and random write due to usage over time. Tested on Nexus 4 and it worked, yay!
Do note that this app contains ads from doubleagent and admob as some reported on the original thread.Take a look at AuxLV LagFix (fstrim) original thread here. AuxLV LagFix (fstrim) FAQs here.
backfromthestorm also compiled a flashable script to do fstrim using CWM recovery. take a look at his post here or download the fstrim CWM packages as follows:
- fstrim for /system, /data. and /cache here (works on Nexus 4 too!)
- fstrim for /data and /cache here
- fstrim on reboot here
It seems there's a typo inside the above fstrim init.d script. here's a fix from JPBeard21:
Last edited:
