The Nexus 7 (2013) Review

eMMC and FSTRIM

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:

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).