Nexus Storage Performance Over Time & TRIM
Breaking news, this' just in:
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
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
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?
- 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:
Current work around:
- use AuxLV's LagFix (fstrim) app from Google Play weekly. (highly recommended)
- use backfromthestorm fstrim init.d to fstrim on each reboot flashed using CWM recovery, no crontab yet, but much appreciated. (highly recommended)
- use your storage wisely, keeping your free space available at 25% available or more to avoid significant slow write degradation. (highly recommended)
- 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:
My take on Galaxy Nexus 16GB storage performance (eMMC VYL00M rev. 0x25):
- VYL00M (insignificant effect)
- V3U00M (significant effect)
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:
My take on Nexus 4 16GB storage performance:
- SW from 3.91MBps to 6.96MBps ~ 78% gain
- RW is the same on 0.23MBps ~ no gain/loss
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.
Credits (notify me if I forgot to add you here):
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
Earlier Samsung told us that all review samples including our three shipped with a pre-production firmware that had a bug in it causing the failures (retail units were shipped with a newer firmware without the bug). At the time we didn't know what exactly was wrong in the firmware, but now we do. When the drive was issued a secure erase command, it would clear all table mapping information at the Address Translation Layer (ATL) but not at the Host Interface Layer (HIL). The data in both layers needs to be up-to-date for the drive operate properly, so when a write request came in, the controller wasn't able to map the data correctly, which caused the firmware to hang. An SSD obviously can't operate without a functioning firmware so from a user's standpoint, it looked like the drive had completely died even though only its firmware was broken.
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
TRIM is a SATA command that enables the operating system to tell an SSD what blocks of previously saved data are no longer needed as a result of file deletions or using the format command. When an LBA is replaced by the OS, as with an overwrite of a file, the SSD knows that the original LBA can be marked as stale or invalid and it will not save those blocks during garbage collection. If the user or operating system erases a file (not just remove parts of it), the file will typically be marked for deletion, but the actual contents on the disk are never actually erased. Because of this, the SSD does not know the LBAs that the file previously occupied can be erased, so the SSD will keep garbage collecting them.
The introduction of the TRIM command resolves this problem for operating systems which support it like Windows 7, Mac OS (latest releases of Snow Leopard, Lion, and Mountain Lion, patched in some cases), and Linux since 2.6.33. When a file is permanently deleted or the drive is formatted, the OS sends the TRIM command along with the LBAs that are no longer containing valid data. This informs the SSD that the LBAs in use can be erased and reused. This reduces the LBAs needing to be moved during garbage collection. The result is the SSD will have more free space enabling lower write amplification and higher performance.
The actual benefit of the TRIM command depends upon the free user space on the SSD. If the user capacity on the SSD was 100 GB and the user actually saved 95 GB of data to the drive, any TRIM operation would not add more than 5 GB of free space for garbage collection and wear leveling. In those situations, increasing the amount of over-provisioning by 5 GB would allow the SSD to have more consistent performance because it would always have the additional 5 GB of additional free space without having to wait for the TRIM command to come from the OS.