Breaking news, this' just in: 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!)
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?
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:
use backfromthestormfstrim 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.
Sent from my Galaxy Nexus using xda app-developers app
Yeah, i never thought this would happen. Hehe
Quote:
Originally Posted by peachpuff
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
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.
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.
The default boot animations on any device, no matter whichmanufacturer, are generally pretty … more
XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality. Are you a developer?
Introducing XDA:DevCon – A Conference For Developers By Developers
>
Nexus Storage Performance Over Time & TRIM
Print
Email
Nexus Storage Performance Over Time & TRIM
Do note that this app contains ads from doubleagent and admob as some reported on the original thread.
View Profile
View Forum Posts
Visit Homepage
Linear Mode
