Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,769,298 Members 39,400 Now Online
XDA Developers Android and Mobile Development Forum

Nexus Storage Performance Over Time & TRIM 20130829

Tip us?
 
chrone
Old
(Last edited by chrone; 29th August 2013 at 05:27 PM.) Reason: update source link of the new f2fs on moto x device
#1  
chrone's Avatar
Senior Member - OP
Thanks Meter 389
Posts: 1,025
Join Date: May 2012
Location: Surabaya
Default Nexus Storage Performance Over Time & TRIM 20130829

Quote:
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/a...-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:
  • 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:
  • 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.

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.

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

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

Quote:
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:
Attached Thumbnails
Click image for larger version

Name:	galaxy nexus storage performance.jpg
Views:	46689
Size:	62.8 KB
ID:	1454079   Click image for larger version

Name:	androbench on gnex running android 4.2.1.jpg
Views:	44880
Size:	45.2 KB
ID:	1541704   Click image for larger version

Name:	nexus 4 androbench before and after.jpg
Views:	53421
Size:	64.8 KB
ID:	1666492   Click image for larger version

Name:	nexus 4 androbench reboot and fstrim.jpg
Views:	53369
Size:	65.5 KB
ID:	1666493  
Attached Files
File Type: zip Fstrim_sys_CWM.zip - [Click for QR Code] (1.27 MB, 335 views)
File Type: zip Fstrimmer_data_CWM.zip - [Click for QR Code] (1.27 MB, 293 views)
File Type: zip fstrim_log_init.zip - [Click for QR Code] (146.3 KB, 453 views)
LGE Nexus 5 16GB Black: Android KitKat.
efrant's Android 101 for Nexus 4
The Following 45 Users Say Thank You to chrone For This Useful Post: [ Click to Expand ]
 
kizakiyuria
Old
#2  
kizakiyuria's Avatar
Senior Member
Thanks Meter 60
Posts: 136
Join Date: Oct 2012
Location: surabaya
i'm wondering too


Sent from my Galaxy Nexus using xda app-developers app


Rom : AOKP Official Nightlies

Kernel : Lastest FuguMod Kernel

Recovery : CWM 6.0.3.1 touch

Swagger On!!!
 
peachpuff
Old
#3  
peachpuff's Avatar
Senior Member
Thanks Meter 298
Posts: 1,469
Join Date: Aug 2010
My sequential write is down to 2.27mb/sec
Captivate + cm7
HP Touchpad + cm9
SGS2 + cm9
Galaxy Nexus + CNA
LG Nexus 4 + AOKP
LG Nexus 5 + Xposed
The Following User Says Thank You to peachpuff For This Useful Post: [ Click to Expand ]
 
Sdobron
Old
#4  
Senior Member
Thanks Meter 358
Posts: 2,063
Join Date: Sep 2010

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

The Following User Says Thank You to Sdobron For This Useful Post: [ Click to Expand ]
Soldier-2Point0 Old
#5  
Guest
Thanks Meter
Posts: n/a
Looks like someone has been changing ROMs without doing a factory reset...

Sent from my Nexus 7 using xda premium
 
chrone
Old
(Last edited by chrone; 4th November 2012 at 04:02 AM.)
#6  
chrone's Avatar
Senior Member - OP
Thanks Meter 389
Posts: 1,025
Join Date: May 2012
Location: Surabaya
Quote:
Originally Posted by Teezekel View Post
Interesting



Quote:
Originally Posted by kizakiyuria View Post
i'm wondering too


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




Quote:
Originally Posted by peachpuff View Post
My sequential write is down to 2.27mb/sec
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.




Quote:
Originally Posted by Sdobron View Post
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
LGE Nexus 5 16GB Black: Android KitKat.
efrant's Android 101 for Nexus 4
 
BrianDigital
Old
#7  
BrianDigital's Avatar
Senior Member
Thanks Meter 309
Posts: 2,794
Join Date: Jun 2009
Location: Philadelphia, Pennsylvania, United States

 
DONATE TO ME
Quote:
Originally Posted by Soldier-2Point0 View Post
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 ----------

Quote:
Originally Posted by Sdobron View Post
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
 
chrone
Old
#8  
chrone's Avatar
Senior Member - OP
Thanks Meter 389
Posts: 1,025
Join Date: May 2012
Location: Surabaya
Quote:
Originally Posted by BrianDigital View Post
Is fsync turned off in faux?

Sent from my Nexus 7 using Tapatalk 2
Is fsync enabled by default on stock kernel? That explains the slow performance on write but with safer data.

Sent from my Galaxy Nexus
LGE Nexus 5 16GB Black: Android KitKat.
efrant's Android 101 for Nexus 4
 
GldRush98
Old
(Last edited by GldRush98; 3rd August 2013 at 11:15 PM.) Reason: Incorrect information. My apologies.
#9  
GldRush98's Avatar
Senior Member
Thanks Meter 266
Posts: 2,165
Join Date: Jun 2006
Location: Taylorville, IL.
Disregard
---Phone---
Nexus 5 32gb
Android 4.4.4 KTU84P, Baseband 2.0.50.1.16, Unlocked, rooted, TWRP Recovery 2.7.1.1
---Tablets---
Samsung Note 10.1 2014 Edition 32gb
Android 4.4.2 KOT49H, rooted, TWRP 2.6.3.3
Nexus 7 16gb
Android 4.4.2 KOT49H, Unlocked, rooted, TWRP Recovery 2.6.3.1
---Past---
Galaxy Nexus (AT&T)
Android 4.3 JWR66Y, Baseband I9250XXLJ1, Unlocked, rooted, Clockwork Touch 6.0.4.3
Google Nexus One | AT&T Fuze (Touch Pro) | AT&T 8525 (Hermes) | AT&T 8125 (Wizard)
The Following 7 Users Say Thank You to GldRush98 For This Useful Post: [ Click to Expand ]
 
Smokeey
Old
#10  
Senior Member
Thanks Meter 321
Posts: 1,646
Join Date: Oct 2010
Location: Anaheim, CA
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

"the definition of open: 'mkdir android ; cd android ; repo init -u git://android.git.kernel.org/platform/manifest.git ; repo sync ; make'" -Andy Rubin

Devices:
Droid Incredible
Samsung Galaxy Nexus[LTE]
LG G2[T-Mobile]

Tags
fstrim, nexus, random write, sequential write, trim
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes