One of the common complaints late in the life of the original Nexus 7 was slow storage I/O performance, leading to an inconsistent user experience. After a fresh flash, the Nexus 7 was speedy and performant, but after months of installing applications and using the tablet, things began slowing down. This was a friction point that many hoped would be fixed in the new Nexus 7 (2013) model, which it was. There’s even more to the story though, it turns out Google has fixed that storage I/O aging problem on all Nexus devices with the Android 4.3 update.

In our Nexus 7 (2013) review, I talked about how I had confirmed that Android 4.3 onboard the device had enabled support for fstrim, an application which TRIMs blocks not in used by the filesystem. TRIM is essentially the paging channel through which the OS tells an SSD or eMMC controller that a block is no longer in use, and thus ready for garbage collection. This is critical for maintaining performance on the controllers in use across smartphones and tablets and preventing aging-related I/O performance slowdown.

Remember that deleting a file in software isn't actually communicated to solid state storage (whether SSD or eMMC). The space is freed up from the user's perspective, but the eMMC controller in this case still treats the pages in NAND as having valid data. Let's say you copy a 3GB movie to your internal storage, watch the movie and later delete it. You'd have 3GB free to re-use, but until you re-write those blocks the eMMC controller would treat all 3GB as valid data. There's a data structure used by the eMMC controller that tracks mapping logical locations to physical locations in NAND. I won't go into great detail here but the more complex that mapping becomes, and the more locations that have to be tracked, the slower internal NAND management works.
 
TRIM (and its equivalents) establishes that communication between file system and eMMC/NAND controller. When unused blocks are TRIMed at the OS level, a signal is sent to the eMMC controller telling it that it no longer has to track that data. A good controller will then schedule those NAND pages/blocks for garbage collection/recycling, thus improving performance. Note the use of the phrase "good controller". Enabling TRIM support is most definitely the first step though.

Although I had searched for direct confirmation before posting the Nexus 7 (2013) review, and had found some references to it, a reader of ours found fstrim inside vold (the volume daemon) and the notes essentially describe what I’ve said already.

I’ve learned a bit more on the conditions underlying when Android 4.3 will TRIM filesystems, as it wasn’t completely clear before. 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.

Fstrim sends the FITRIM ioctl() command to all writable filesystems when invoked, which discards (TRIMs) blocks on the eMMC not used by the filesystem. Without TRIM the controller will track blocks that have data deleted by the filesystem, but the controller still believes has data it needs to track. TRIM is the signaling pathway through which the filesystem and OS can tell the controller that it can now consider those blocks unused and for garbage collection – different controllers will behave differently since it’s their prerogative to decide what happens next however.

It’s also easy to check and see that fstrim is running on devices over adb, by running and looking for it:

adb logcat -d | grep -i fstrim

Example output from a few Nexus devices I have handy which have been on for over 24 hours and have the Android 4.3 update installed.

Nexus 7 (2013)

┌─[brianklug@MBP] - [~/Downloads/APKs] - [Mon Jul 29, 03:30]
└─[$] <> ./adb  logcat -d | grep -i fstrim
I/fstrim  (  172): Starting fstrim work...
I/fstrim  (  172): Invoking FITRIM ioctl on /cache
I/fstrim  (  172): Trimmed 564789248 bytes on /cache
I/fstrim  (  172): Invoking FITRIM ioctl on /data
I/fstrim  (  172): Trimmed 25105637376 bytes on /data
I/fstrim  (  172): Invoking FITRIM ioctl on /persist
I/fstrim  (  172): Trimmed 0 bytes on /persist
I/fstrim  (  172): Finished fstrim work.
I/fstrim  (  172): Starting fstrim work...
I/fstrim  (  172): Invoking FITRIM ioctl on /cache
I/fstrim  (  172): Trimmed 0 bytes on /cache
I/fstrim  (  172): Invoking FITRIM ioctl on /data
I/fstrim  (  172): Trimmed 1045696512 bytes on /data
I/fstrim  (  172): Invoking FITRIM ioctl on /persist
I/fstrim  (  172): Trimmed 0 bytes on /persist
I/fstrim  (  172): Finished fstrim work.

Nexus 7 (2012)

┌─[brianklug@MBP] - [~/Downloads/APKs] - [Mon Jul 29, 03:46]
└─[$] <> ./adb  logcat -d | grep -i fstrim
I/fstrim  (  122): Starting fstrim work...
I/fstrim  (  122): Invoking FITRIM ioctl on /cache
I/fstrim  (  122): Trimmed 122961920 bytes on /cache
I/fstrim  (  122): Invoking FITRIM ioctl on /data
I/fstrim  (  122): Trimmed 1087574016 bytes on /data
E/fstrim  (  122): Cannot stat mount point /radio
I/fstrim  (  122): Finished fstrim work.
I/fstrim  (  122): Starting fstrim work...
I/fstrim  (  122): Invoking FITRIM ioctl on /cache
I/fstrim  (  122): Trimmed 118923264 bytes on /cache
I/fstrim  (  122): Invoking FITRIM ioctl on /data
I/fstrim  (  122): Trimmed 782077952 bytes on /data
E/fstrim  (  122): Cannot stat mount point /radio
I/fstrim  (  122): Finished fstrim work.
 

Nexus 4

┌─[brianklug@MBP] - [~/Downloads/APKs] - [Mon Jul 29, 03:47]
└─[$] <> ./adb  logcat -d | grep -i fstrim
- waiting for device -
I/fstrim  (  169): Starting fstrim work...
I/fstrim  (  169): Invoking FITRIM ioctl on /cache
I/fstrim  (  169): Trimmed 115343360 bytes on /cache
I/fstrim  (  169): Invoking FITRIM ioctl on /data
I/fstrim  (  169): Trimmed 888254464 bytes on /data
I/fstrim  (  169): Invoking FITRIM ioctl on /persist
I/fstrim  (  169): Trimmed 0 bytes on /persist
I/fstrim  (  169): Finished fstrim work.
I/fstrim  (  169): Starting fstrim work...
I/fstrim  (  169): Invoking FITRIM ioctl on /cache
I/fstrim  (  169): Trimmed 113246208 bytes on /cache
I/fstrim  (  169): Invoking FITRIM ioctl on /data
I/fstrim  (  169): Trimmed 1431195648 bytes on /data
I/fstrim  (  169): Invoking FITRIM ioctl on /persist
I/fstrim  (  169): Trimmed 0 bytes on /persist
I/fstrim  (  169): Finished fstrim work.

Users who have been experiencing slow I/O performance should see an improvement after getting the Android 4.3 update and letting fstrim run in the background a few times. Anand (the resident king of SSD and TRIM) is running some tests to investigate how much I/O performance can vary after an fstrim run. 

POST A COMMENT

46 Comments

View All Comments

  • steven75 - Thursday, August 01, 2013 - link

    Great that Google fixed this.

    I can't imagine having the N7 for an entire year before this major problem was resolved though. I guess it's another case of getting what you pay for.
    Reply
  • Charlie Bing - Thursday, August 01, 2013 - link

    FINALLY! Reply
  • DeniZz - Friday, August 02, 2013 - link

    "Android 4.3 Fixes First-Gen Nexus 7 Slowdown Issue", "Google Android 4.3 to the Rescue for Old & Laggy Nexus 7", "Android 4.3 may breathe new life in your bogged down Nexus 7", blah-blah-blah... First of all, why just Nexus 7? Buggy eMMC V3U00M is in many devices - HTC One X, SGS3, my Galaxy Nexus and maybe in others. Another question, why we should be very happy with our buggy devices after 4.3 update? TRIM doesn't help get rid of lags and slowdowns, when there's less than 3 GB free memory. With less than 1GB of free space available my GNex slow as hell, and TRIMing and DISCARDing doesn't help at all. And what a strange schedule for automatic "idle maintenance"? When should I charge my phone and let it idle for maintenance start? I've charged it every night for a week, and it never started "idle maintenance", because I haven't seen any trims in logcat and any speed improvements in androbench. And is there any way to force that fstrim process manually without root and lagfix app in 4.3?
    I don't think that "quietly added TRIM support" in 4.3 is cure-all for devices with eMMC V3U00M.
    Reply
  • BC2009 - Thursday, August 15, 2013 - link

    I'm confused.... is Android implementing TRIM for solid state storage that does not otherwise support it or is Android just now supporting TRIM when it is implemented on the solid state storage?

    I didn't think that TRIM was something that had to run in the background. Is the background process just cleaning up all the stuff that accumulated before Android 4.3 was installed on the device?

    Did I simply misunderstand how TRIM was implemented normally?
    Reply
  • Badelhas - Wednesday, November 20, 2013 - link

    Should we do a full wipe when upgrading or we gain performance over time when we do a OTA upgrade? Reply
  • Chromejob - Sunday, March 23, 2014 - link

    Having upgraded my 2012 N7 16gb to 4.3 I found immediate improvement (well who wouldn't if you did a fresh wipe), but after a while, it slowed down again.

    A colleague recommended I run logcat against "fstrim" or even just "trim." If ordinarily finds nothing:

    platform-tools]$ adb logcat -d -b main -b system -b events |grep trim

    After running lagfix (yeah, I know I shouldn't have to, but I found it DOES immediate good to my N7's response, irregardless of available RAM), I find the following:

    [dspaldin@dspaldin platform-tools]$ adb logcat -d -b main -b system -b events |grep trim
    I/EsApplication( 5056): Trimming memory (onTrimMemory 20)
    I/EsApplication( 5056): Trimming memory (onTrimMemory 5)
    I/EsApplication( 5056): Trimming memory (onTrimMemory 20)
    I/EsApplication( 5056): Trimming memory (onTrimMemory 80)

    I'm not sure that fstrim is working properly even in the current version, 4.4.2. Pity, the Nexus 7 '12 shouldn't have become obsolete so soon.
    Reply

Log in

Don't have an account? Sign up now