Nexus Storage Performance Over Time & TRIM 20150508

chrone

Senior Member
May 5, 2012
1,050
369
0
Surabaya
Android 4.3 Update Brings TRIM to All Nexus Devices
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.
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:
  1. Anandtech: Exploring the Relationship Between Spare Area and Performance Consistency in Modern SSDs
  2. Anandtech: Asus Nexus 7 Storage Performance
  3. Anandtech: SSD Anthology
  4. Anandtech: Performance Over Time and TRIM
  5. Wikipedia: TRIM
  6. Debian Linux SSD Optimization
  7. Impact of ext4′s discard option on my SSD
  8. Android on eMMC: Optimizing for Performance
  9. 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:

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. :D

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.

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. :D

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.

resources:

---

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.

There are two versions of LagFix:
LagFix (fstrim) Premium version - no ads + ability to auto-run trimming on specified schedule. The best choise!
LagFix (fstrim) Free version - trims your memory with one click, has ads, no schedule.

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:
 

Attachments

Last edited:
S

Soldier-2Point0

Guest
Looks like someone has been changing ROMs without doing a factory reset...

Sent from my Nexus 7 using xda premium
 

chrone

Senior Member
May 5, 2012
1,050
369
0
Surabaya
Interesting :D



i'm wondering too
:D

Sent from my Galaxy Nexus using xda app-developers app
Yeah, i never thought this would happen. Hehe




My sequential write is down to 2.27mb/sec :eek:
Whoa, did you frequent use your storage with lots of small and big file sizes?

I guess you do a lot of write-delete-write cycle like me. I get new hobby to watch 720p movies and hdtv series on this gnex, and total Bit written in my storage were over 16GB, hence the flash memory or nand's write amplication occured and slowed down both sequential and random write speed.




Never reset my phone to stock and my numbers are all much better than yours. Using Faux kernel with FIOPS scheduler
Now that is awesome! Stock kernel didn't have this tweak on storage performance. hope they will add this feature on next build.

Sent from my Galaxy Nexus
 
Last edited:

BrianDigital

Senior Member
Looks like someone has been changing ROMs without doing a factory reset...

Sent from my Nexus 7 using xda premium
I would point to how much free space is left rather than that wiping everytime a rom is changed....

Sent from my Nexus 7 using Tapatalk 2

---------- Post added at 05:28 AM ---------- Previous post was at 05:26 AM ----------

Never reset my phone to stock and my numbers are all much better than yours. Using Faux kernel with FIOPS scheduler

Is fsync turned off in faux?

Sent from my Nexus 7 using Tapatalk 2
 

BrianDigital

Senior Member
Is fsync enabled by default on stock kernel? That explains the slow performance on write but with safer data. :)

Sent from my Galaxy Nexus
Yes it is enabled in stock setups, turning it off just leaves the stuff in ram it also tricks benchmarking tests with inaccurate data since its not doing the writing


To the op my stock gnex has results more akin to the after trim results how much storage do you have free
Sent from my Nexus 7 using Tapatalk 2
 
  • Like
Reactions: chrone

chrone

Senior Member
May 5, 2012
1,050
369
0
Surabaya
First off, trim is a command, and more specifically an ATA command. It has nothing to do with eMMC storage. There is no such thing for eMMC.
Second off, eMMC doesn't really need to be trim'ed like SSD's do. The eMMC 4.5 spec did include a discard sub-operation, but it is really not beneficial, especially on our low storage capacity mobile devices.
thanks for the heads up. unfortunately a lot of nexus 7 users report slow performance once their sdcard was fulled with data and the regression was pretty much down to below 1Mbps for sequential write. take a look the bugs reported on android open source project.


There is absolutely no point at all in doing this. The increase is so small that its just a waste of time.

Sent from my Galaxy Nexus using xda app-developers app
same as the above.


Yes it is enabled in stock setups, turning it off just leaves the stuff in ram it also tricks benchmarking tests with inaccurate data since its not doing the writing


To the op my stock gnex has results more akin to the after trim results how much storage do you have free
Sent from my Nexus 7 using Tapatalk 2
oh okay, nice to know that. :)

the available storage left around 3-5gb i guess?
forgot to check when it's down to 5Mbps sequential write. i watched supernatural season 1 to season 6 using gnex before reset to factory image, and the total amount of the serial was more less 42Gb, thus frequent copy-watch-delete thing. :D

care to vote for bug fix on android open source project as follows? more than 200 people voted this bug to be fix or this feature to be implemented. hope google will listen.

the bug report link, to vote on this following link, click the star button below add comment section at bottom of adroind open source project but report page:
https://code.google.com/p/android/issues/detail?id=37258
 
Last edited:

markop90

Senior Member
Feb 16, 2011
443
113
0
Same issue here... If my free space goes below 3gb the phone begins to slow down horribly... Until I factory-reset it....

Random writes <0.50 mb/s on androbench
 
  • Like
Reactions: chrone

Sdobron

Senior Member
Sep 5, 2010
2,351
418
0
I would point to how much free space is left rather than that wiping everytime a rom is changed....

Sent from my Nexus 7 using Tapatalk 2

---------- Post added at 05:28 AM ---------- Previous post was at 05:26 AM ----------



Is fsync turned off in faux?

Sent from my Nexus 7 using Tapatalk 2
I'm pretty sure I recall reading it's off but I'm not 100% sure...
 
  • Like
Reactions: chrone

zero_x3

Member
Oct 25, 2010
20
7
0
I usually have about 1 or 2 movies (~700MB or ~1.6GB) on my phone at a time and never had any problems. One day, I felt ambitious to watch a few movies and pretty much got my GNex to under 3GB. Since then, it hasn't been the same.

What I have
GSM Galaxy Nexus
yakjuxw
4.1.1 stock
Unlocked and Rooted
Baseband version I9250XXLF1
Kernel Version 3.0.31-g6fb96c9
Build Number JRO03C.I9250XWLH2

What I've tried
  • Clearing up movies, camera pictures/videos
  • Uninstalling recent apps
  • Clearing app/browser caches

AndroBench Results with 8.14GB available
  • Sequential Read = 1.97 MB/s
  • Sequential Write = 0.14 MB/s
  • Random Read = 0.39 MB/s, 101.47 IOPS(4K)
  • Random Write = 0.0 MB/s, 1.76 IOPS(4K)

EDIT: Converted from Yakjuxw to yakju using this and now running stock 4.1.2. Now my AndroBench is
26.93 MB/s
12.21 MB/s
8.98 MB/s
0.52 MB/s
 
Last edited:
  • Like
Reactions: Exnor and chrone

chrone

Senior Member
May 5, 2012
1,050
369
0
Surabaya
Same issue here... If my free space goes below 3gb the phone begins to slow down horribly... Until I factory-reset it....

Random writes <0.50 mb/s on androbench
I usually have about 1 or 2 movies (~700MB or ~1.6GB) on my phone at a time and never had any problems. One day, I felt ambitious to watch a few movies and pretty much got my GNex to under 3GB. Since then, it hasn't been the same.

What I have
GSM Galaxy Nexus
yakjuxw
4.1.1 stock
Unlocked and Rooted
Baseband version I9250XXLF1
Kernel Version 3.0.31-g6fb96c9
Build Number JRO03C.I9250XWLH2

What I've tried
  • Clearing up movies, camera pictures/videos
  • Uninstalling recent apps
  • Clearing app/browser caches

AndroBench Results with 8.14GB available
  • Sequential Read = 1.97 MB/s
  • Sequential Write = 0.14 MB/s
  • Random Read = 0.39 MB/s, 101.47 IOPS(4K)
  • Random Write = 0.0 MB/s, 1.76 IOPS(4K)

This last AndroBench test is just horrible.
same boat here. reset to factory image does format the sdcard and the performance is back to normal again. i hope they do fix this on next build to trigger a command something like TRIM on SSD without having the need to reset to factory image periodically. please vote at the bottom page of page one for Android dev to hear us out regarding this problem. this happens on Nexus 7 as well. :)
 
  • Like
Reactions: szaszi1

ph4zrd

Senior Member
Nov 30, 2012
72
88
0
Dresden, Saxony
Mounting the relevant partitions with ext4's discard option (as I suggested on code.google.com/p/android/issues/detail?id=39154) seems to fix the problem. You may then fill the filesystem with zeros using dd and simply delete the created file afterwards.
 
  • Like
Reactions: chrone