The new Nexus 7 obviously ships with the latest version of Android (4.3), which happens to add a major feature for keeping storage performance high: fstrim. Modern smartphones and tablets fundamentally use a very similar storage architecture to what we see in modern SSDs (solid state drives) in PCs. Instead of a drive featuring a discrete controller, DRAM and NAND flash, these ultra mobile devices typically feature one or two NAND devices with an integrated controller - typically eMMC. To keep costs (and power consumption) low there's also no DRAM cache, which definitely harms performance.

Since the underlying architectures are quite similar, the pitfalls are the same as well. The biggest issue? Performance when operating in a full or near-full state. With tons of files on your internal storage, the data structures that have to track all of those files and where they're located in NAND space get pretty complex, and traversing those structures takes a considerable amount of time. The part that many seem to forget is that once you delete a file in Android, it's not immediately removed from internal storage. The space is freed up in the OS, but the eMMC controller still tracks all of the data as valid bits. It's only when that data is overwritten that the controller knows the previous data didn't matter.

In other words, it's possible to have tons of free space on your internal storage, but have the drive appear full to the eMMC controller (and thus enjoy all of the terrible performance that goes along with it). To make matters worse, you never even have to fill your drive to get it into this state. In order to maintain even wear across all NAND cells (to extend the lifespan of the NAND flash), the eMMC controller will write to new/empty blocks in NAND as much as possible. Let's say you have 10GB of storage and Android writes 1GB of data to new addresses every month and deletes the previous 1GB each time. As long as the addresses being written to never overlap, your drive will be full in 10 months (from the eMMC controller's perspective) but Android will still report 9GB of free space.

fstrim establishes communication between the OS and the eMMC controller to address this problem - and it's enabled in Android 4.3.

Unlike TRIM on standard SSDs, FS_TRIM works more like the manual/scheduled TRIM tools from the early days of consumer SSDs. From Brian's original Android 4.3/TRIM article:

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.

Personally I feel like the rules are a bit excessive and I'd love to see us get to active TRIM on these devices, but I guess it's a bit too early for that. Basically if your device has enough charge and you're not using it, Android 4.3 will issue an fstrim command to the eMMC controller. The command passes along a list of all unallocated addresses in the filesystem, which the eMMC controller can then use to purge its logical to physical mapping table/list/datastructure. The process should complete relatively quickly as no new data has to be written, the controller just needs to do some cleanup of internal structures and add a bunch of addresses to the unused block pool. Keep in mind that this simply addresses the issue of your storage getting slower over time. fstrim does nothing to keep performance high if you actually fill your storage to capacity. Given how bad these eMMC solutions are, my recommendation is to try and keep at least 20% of your internal storage unused/as free space.

To showcase just how bad things can get I actually dusted off last year's Nexus 7 and treated it like an SSD. I first filled the device with sequential data, leaving only 300MB free. I then performed back to back random writes across the remaining free space and the performance reduction:

Nexus 7 (2012) Storage Performance
  Sequential Read Sequential Write Random Read Random Write
New After Factory Reset 25.18 MB/s 10.63 MB/s 7.08 MB/s 0.45 MB/s
1st Run After Fill 22.25 MB/s 1.21 MB/s 7.62 MB/s 0.14 MB/s
2nd Run After Fill 26.00 MB/s 1.97 MB/s 7.8 MB/s 0.11 MB/s
3rd Run After Fill 24.57 MB/s 3.18 MB/s 7.96 MB/s 0.16 MB/s
After ~24 hours Idle Time 27.03 MB/s 11.21 MB/s 7.65 MB/s 0.46 MB/s

The columns to pay the most attention to are the write columns (read performance shouldn't change over time). Note that sequential write speed drops by almost an order of magnitude. This incredible drop in performance manifests itself as pauses or stutters. Even when you're just performing simple tasks on your tablet, there are usually tons of background operations going on (e.g. updating system logs). If you look at random write performance here, we see performance drop down to 0.11MB/s - or roughly 27 IO operations per second. If you have more than that amount of IO coming in at the same time, what you'll get are long pauses while the eMMC controller works through its IO queue. Although I didn't include it in the table above, I spent a full day torturing the eMMC on this Nexus 7 and managed to get random write performance as low as 0.02MB/s or 5 IOPS. Sequential write performance in that case was 0.81MB/s, equally disheartening. My point here is that worst case storage performance can get very bad, but looking at the last line of the table you see the incredible impact fstrim has on restoring performance.

I/fstrim ( 118): Starting fstrim work...
I/fstrim ( 118): Invoking FITRIM ioctl on /cache
I/fstrim ( 118): Trimmed 445079552 bytes on /cache
I/fstrim ( 118): Invoking FITRIM ioctl on /data
I/fstrim ( 118): Trimmed 13637656576 bytes on /data
I/fstrim ( 118): Finished fstrim work.

Anyone who had issues with their Nexus 7 slowing down over time will want to upgrade to Android 4.3. Those users considering upgrading to the new Nexus 7 should be fine thanks to fstrim. The only situation where you should see tremendous decrease in storage performance, resulting in IO latency enduced pausing/stuttering is if you physically fill the internal storage close to capacity. Again - my recommendation here is to try and leave at least 20% of your internal storage free. Note that this recommendation applies across Android and iOS.

With all of that out of the way, how does the eMMC solution in the new Nexus 7 stack up? Sequential read performance continues to be quite good for such a small/lower power device. Sequential write speed isn't terrible either. Even random read performance looks solid. It's random write performance that just needs work across the industry. We realistically need to probably be at 10x where we are today in random write performance, perhaps a bit lower if the storage makers can focus on IO consistency/minimum sustained IOPS.

Storage solutions in these tablets are often sourced from multiple vendors, and we can see dramatic differences in performance between them. Brian's review sample was a 32GB model, while the tablet I reviewed had 16GB. The two solutions performed pretty similarly, although my 16GB model did have appreciably better random write performance. Ultimately if you need the space, the 32GB model will be the better performer (you're better off using 45% of a 32GB model than 90% of a 16GB model).

Storage Performance - 256KB Sequential Reads

Storage Performance - 256KB Sequential Writes

Storage Performance - 4KB Random Reads

Storage Performance - 4KB Random Writes


CPU & GPU Performance WiFi, GPS & Camera
Comments Locked


View All Comments

  • scavio - Thursday, August 22, 2013 - link

    Seems odd that you compare the display to an iPad 4 and say you won't even bother comparing it to other android tablets. As far as I can tell you don't even include the iPad 4 in any of the graphs except pixel density and do include a bunch of android tablets.
  • andykins - Thursday, August 22, 2013 - link

    I noticed that too. You should include the retina ipad display in the graphs imo. Also redefines has been misspelt on the final paragraph of final words.

    Good article. Tempting :)
  • Anand Lal Shimpi - Thursday, August 22, 2013 - link

    Fixed :)
  • scavio - Thursday, August 22, 2013 - link

    Thanks! The numbers really are close, I'm impressed.
  • jiffylube1024 - Thursday, August 22, 2013 - link

    Some of the tests (eg 3d mark) don't run on iOS, which explains the ipad 4's absence.
  • mmarafie - Thursday, August 22, 2013 - link

    The comparison to the iPad 4 is a way to detract from the real competitor to Nexus 7, the iPad mini. Not only does the Nexus 7 offer much better color accuracy than the iPad mini, it also has double the pixel density at 323 compared to 163...Anand calls the SOC in the N7 "performance mainstream" which has a Quad Core Krait @ 1.5GHz and 2GB RAM. Yet he omits to mention the paltry (2 year old) SOC in the iPad mini a Cortex A8 based Dual Core CPU running 1GHz with 512MB RAM and a GPU that is less than half the power of the Adreno 320 in the N7...
  • mmarafie - Thursday, August 22, 2013 - link

    Yes in general, apps are still slightly better optimized on iOS, but Android apps are closing in fast not only in quantity but also in quality. So a properly optimized app on N7 can easily get 2 to 4x CPU/GPU power compared to iPad mini. Also Anand omits mentioning the price deference between the N7 at only $240 compared with the iPad mini at $340. I understand the better build quality on the iPad, but paying $100 more for the comparatively pixelated screen and weak hardware of the iPad mini is just plain ridiculous...For the 32GB 4G version it gets even worse, the N7 costs only $350, while the iPad mini costs $660! Is this a joke or what? Again Anand omits to mention any of that...
  • mmarafie - Thursday, August 22, 2013 - link

    Sorry, meant to say $560 for the 32GB 4G version of the iPad mini
  • dyc4ha - Thursday, August 22, 2013 - link

    Well, the fact that it is being compared to Apple's flagship tablet says mighty much already... I do not see the need to compare it directly with the Mini because, well, there isn't a comparison. I enjoyed the review btw, keep it up!
  • mmarafie - Friday, August 23, 2013 - link

    If someone is in the market for a smaller tablet say in the 7 to 8" size range, then they would be looking at say the Nexus 7, iPad mini, Galaxy Tab 3 and Note 8.0, Asus MeMo Pad etc. So these are the tablets that should be compared directly with each other in review. Although it's still a good idea to have benchmarks of the larger tablets for comparison too.

    To me the review is incomplete and omitting some variables that could help the buyer make an informed decision.

Log in

Don't have an account? Sign up now