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:

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
POST A COMMENT

202 Comments

View All Comments

  • Arbie - Thursday, August 22, 2013 - link


    No micro/SD card = no sale.

    One of the main reasons I would buy something like this is "media consumption". Nothing - including large internal memory - can compare to SD for swapping media sets in and out. Like.. 16GB in 5 sec. Plus you can carry any number of extra sets with you.

    The continued refusal of Google and Amazon to include SD is sad, at least for me. Fortunately, Samsung does do SD.
    Reply
  • sweenish - Thursday, August 22, 2013 - link

    If it really came down to that for me, I'd go USB OTG with my wife's 1 TB WD Passport. Not as elegant as a microSD card, but I'm plunked down to watch something anyway.

    Otherwise, I'm streaming.
    Reply
  • sherlockwing - Thursday, August 22, 2013 - link

    For me the 32GB is plenty for media consumption on a plane, I can get 47 hours of 720p down to 20G with handbrake and that last me a few days. When I run out of videos I just move in new ones from my laptop. Reply
  • bji - Friday, August 23, 2013 - link

    You watch alot of TV. 47 hours would last me about ... a year. Reply
  • just4U - Saturday, August 24, 2013 - link

    Bji, Some flights can be extremely long and by the sounds of it Sherlock might be one of those types of long haul commuters.. Hah New York To Japan a few times a month might do the trick in having your device stacked full of video. Reply
  • Impulses - Friday, August 23, 2013 - link

    USB OTG plus my 32GB SanDisk USB 3.0 flash drive ($37 during a Newegg deal)... It's wayyy quicker to transfer movies to that drive anyway (at close to 200MB/s, which no micro SD can touch).

    USB OTG works without root even, and I've been seeing small micro-sized flash drives with micro USB connectors if you really need something smaller than a regular flash drive + OTG cable dongle. The former are small enough to always leave plugged in, someone waseven running a kickstarter to sell one such drive.
    Reply
  • Diorarat - Wednesday, October 02, 2013 - link

    Does it work with the N7? Didn't the 2012 N7 lack usb otg support? Reply
  • darwinosx - Thursday, August 22, 2013 - link

    That made me laugh out loud. Get used to it. Even Samsung will be giving up on sd cards. Because they suck. Reply
  • Impulses - Friday, August 23, 2013 - link

    I think there's still a case to be made for them, even though USB OTG works great for me I can see situations where it's not too suitable as an alternative, like when giving a tablet to a child. Reply
  • ESC2000 - Thursday, August 29, 2013 - link

    Do you just reflexively say anything sucks that apple products don't have? Reply

Log in

Don't have an account? Sign up now