Internal Storage Performance

by Anand Shimpi

Stock Android deployments use ext4 formatted partitions for OS and user data. The Moto X’s pseudo-stock Android 4.2.2 uses ext4 for all partitions with the exception of user data storage, which uses F2FS (Flash Friendly File System):

/dev/block/platform/msm_sdcc.1/by-name/system /system ext4
/dev/block/platform/msm_sdcc.1/by-name/fsg /fsg ext4
/dev/block/platform/msm_sdcc.1/by-name/customize /customize ext4
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware ext4
/dev/block/platform/msm_sdcc.1/by-name/userdata /data f2fs
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4
/dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4
/dev/block/platform/msm_sdcc.1/by-name/pds /pds ext3
/sys/kernel/debug /sys/kernel/debug debugfs
/dev/block/platform/msm_sdcc.1/by-name/userdata /mnt/shell/emulated f2fs
/dev/block/platform/msm_sdcc.1/by-name/userdata /storage/emulated/legacy f2fs
/dev/block/dm-0 /mnt/asec/com.cgollner.systemmonitor-1 ext4

As its name implies, F2FS is designed to be better optimized for use on NAND flash based storage - like the integrated eMMC solution used in the Moto X.

Unlike ext4, F2FS is a log-structured file system. A log-structured file system mixes data and log writes together in an attempt to serialize all writes. Ext4, by comparison, is a journaling file system that keeps track of all file system changes in a journal. A centrally located journal basically means all writes end up looking pseudo-random from the perspective of the storage device, since all writes involve writing the actual data as well as updating the journal located somewhere else in storage space. Log-structured file systems attempt to write both data and file system updates sequentially, as a circular log.

The serialization of writes alone is enough to seriously improve performance (look at the ratio of sequential to random write performance on solid state storage), but F2FS also includes some other features that make it very flash friendly. At a high level, F2FS seems to implement many of the same architectural features we see within solid state drives. As long as there’s enough free space, all new writes happen to empty blocks rather than previously used addresses (as a result, real time garbage collection is necessary). There are even similarities down to the underlying organizational structure of F2FS partitions and SSDs, with counterparts existing for flash pages, blocks and planes. Wear leveling obviously isn’t a concern of F2FS, but largely mirroring what happens internally to the eMMC/SSD definitely helps keep performance high. There’s also apparently some file system/storage hardware awareness baked into F2FS as well. TRIM is not only supported, but it appears to be supported on file delete rather than operating as an idle time task as in Android 4.3 with fstrim.

The Moto X uses F2FS on user data partitions, which has tremendous impacts not only on performance but device behavior over time. For starters, the Moto X boasts better random write performance than any other Android device we’ve ever tested:

Random Write (4KB) Performance

My guess is the advantage we’re seeing here has more to do with F2FS serializing log updates rather than Motorola simply implementing better eMMC hardware, although that is still possible as well.

Sequential Write (256KB) Performance

Random Read (4KB) Performance

Sequential Read (256KB) Performance

Sequential speeds are competitive, although random read performance is a bit lower than on the Galaxy S 4. Between Brian’s two review units we have seen the performance of both SanDisk and Toshiba eMMC devices in the Moto X:

Moto X Storage Performance
  Sequential Read Sequential Write Random Read Random Write
SanDisk 16GB 64.34 MB/s 16.26 MB/s 9.95 MB/s 2.92 MB/s
Toshiba 16GB 64.28 MB/s 11.48 MB/s 12.79 MB/s 2.94 MB/s

Random write performance is near identical, but there are some significant differences in sequential write and random read performance. I've always wondered just how much of a difference exists between various eMMC component suppliers within a given hardware platform, so it's good to have some idea with the Moto X. The Toshiba drive's sequential write performance is substantially less than what SanDisk offers, although random read performance favors the Toshiba solution over SanDisk. I have a hunch that most usage models aren't bound by random read performance, which would make the SanDisk solution the better one, but that's speculation on my part.

To really stress the eMMC implementation and F2FS, I filled my 16GB Moto X’s roughly 12GB data partition with sequential data. I left less than 200MB free on the device, and then ran our standard 100MB span of read/write tests. This is the same procedure that left the 2013 Nexus 7 with ~0.1MB/s random write speeds, but in the case of the Moto X we saw a small but nowhere-near-as-bad performance degradation:

Moto X Storage Performance
  Sequential Read Sequential Write Random Read Random Write
New Condition 61.99 MB/s 11.49 MB/s 12.90 MB/s 3.17 MB/s
1st Run After Fill 60.52 MB/s 9.42 MB/s 13.33 MB/s 2.38 MB/s
2nd Run After Fill 62.54 MB/s 10.24 MB/s 13.05 MB/s 2.43 MB/s
3rd Run After Fill 62.00 MB/s 10.42 MB/s 13.38 MB/s 2.24 MB/s
4th Run After Fill 61.90 MB/s 10.12 MB/s 13.03 MB/s 2.04 MB/s
5th Run After Fill 61.16 MB/s 10.01 MB/s 12.92 MB/s 2.40 MB/s

At worst I saw a 50% decrease in random write performance, while still delivering an order of magnitude better performance than the worst case on a 2013 Nexus 7. The combination of eMMC hardware and F2FS appears to give the Moto X relative immunity to the sort of significant slowdowns we’ve seen with other Android eMMC implementations. In other words, based on this data, you could run your Moto X at or near full capacity without significantly compromising user experience.

It gets even better.

I then deleted all of the files I wrote to the F2FS partition to find out if I’d see an immediate improvement in performance. I did:

Moto X Storage Performance
  Sequential Read Sequential Write Random Read Random Write
New Condition 61.99 MB/s 11.49 MB/s 12.90 MB/s 3.17 MB/s
1st Run After Fill 60.52 MB/s 9.42 MB/s 13.33 MB/s 2.38 MB/s
2nd Run After Fill 62.54 MB/s 10.24 MB/s 13.05 MB/s 2.43 MB/s
3rd Run After Fill 62.00 MB/s 10.42 MB/s 13.38 MB/s 2.24 MB/s
4th Run After Fill 61.90 MB/s 10.12 MB/s 13.03 MB/s 2.04 MB/s
5th Run After Fill 61.16 MB/s 10.01 MB/s 12.92 MB/s 2.40 MB/s

Delete ~12GB of Data, Free up Space

1st Run After Delete 61.69 MB/s 12.08 MB/s 12.98 MB/s 3.62 MB/s
2nd Run After Delete 61.90 MB/s 12.06 MB/s 12.56 MB/s 3.96 MB/s
3rd Run After Delete 62.26 MB/s 11.98 MB/s 12.93 MB/s 3.95 MB/s

I waited a few seconds after deleting the ~10GB of data I wrote to the drive before running our storage tests. Apparently that wasn’t long enough as there was a several second pause while writing my 100MB test area to the eMMC device. I suspect the eMMC was still TRIMing the recently freed blocks, causing the pause. Once the test started running however, performance shot up past my first run on the Moto X.

It seems like the Moto X implements TRIM on delete, at least on the F2FS partition. My guess is that TRIM on delete is fairly easy to implement with F2FS given the file system’s SSD-like garbage collection.

Motorola’s decision to include F2FS on the Moto X appears to be a great one from a performance standpoint. The Moto X is the first Android device I’ve used that should be able to keep its performance relatively high while operating in a (nearly) full partition state.

F2FS seems to mirror a lot of the fundamental architecture decisions of high-end SSDs, but at the file system level in software. As eMMC controllers tend to be fairly limited in performance, and eMMC firmware architectures are equally disappointing, leveraging the host OS to do things a little better makes a lot of sense. For the past couple of years I’ve been wondering what the path will be to improve storage performance in mobile devices. I’d previously assumed that we would simply see steady increases in storage performance/complexity, but perhaps we’ll instead see the burden shared by both mobile hardware and the underlying OS/file system.

What are the downsides to F2FS? The big one for me is that I don’t have much experience with the file system. There are always concerns about doing something different, particularly when it comes to trying new file systems on user data. Keep in mind, none of my analysis here has anything to do with reliability or the ability of F2FS to maintain data integrity.

GPU Performance Camera Analysis - One Clear Pixel
POST A COMMENT

104 Comments

View All Comments

  • evilspoons - Monday, August 26, 2013 - link

    It's too bad we don't get any of the customization options in Canada. Rogers is getting the Moto X, but I think it's just in three solid colours. Reply
  • jjj - Monday, August 26, 2013 - link

    Maybe worth mentioning that Atmel has a "Sensor Hub" MCU and it's used in S4 and Surface at least but wasn't highlighted in the marketing so it got zero attention. Reply
  • Honest Accounting - Sunday, September 15, 2013 - link

    Does this function without (waking up) the main CPU cores? Reply
  • nerd1 - Monday, August 26, 2013 - link

    So called 'customization' has been available for samsung phones for AGES.
    Heck they even have freedom of customizing the battery sizes!
    Reply
  • maltanar - Monday, August 26, 2013 - link

    Nice review Brian, thanks. I have a feeling we'll be seeing more and more fixed-function or semi-specific accelerator hardware (read: "cores") in processors in the near future. Not just for mobile applications processors but (over a longer period) for desktop/laptop/server CPUs as well. Reply
  • tim851 - Monday, August 26, 2013 - link

    "I’d posit that the optimal size is somewhere just shy of 5-inches diagonal, say between 4.7 and 5, but this is a subject of heated debate."

    If there's a heated debate, it should be a clue that there is NO OPTIMAL SIZE. People have different use cases for smartphones. I've seen many young girls with tiny hands and huge phones. They don't care for one-handed use. They stuff them in their purses.

    I agree with the point about small screen shouldn't mean small specs.
    Reply
  • retrospooty - Monday, August 26, 2013 - link

    "If there's a heated debate, it should be a clue that there is NO OPTIMAL SIZE. People have different use cases for smartphones. "

    Exactly. It's totally user pref based. It's like asking what is the optimal automobile size. A guy that lives 50 miles from his work, would probably need a small car with good mileage, where a mother with ith 4 kids is better off with a minivan or SUV, and a construction worker needs a truck to haul things. Is one better than the other? No, unless you are talking to the commuter, mother or construction worker.

    As for the phone, looks like a great midrange phone. I like alot of the things MOto is trying to do with it... Should be cheaper though.
    Reply
  • scavio - Monday, August 26, 2013 - link

    Why should it be cheaper? This isn't a Nexus.

    If they are lucky they are saving $10 on the SOC vs a Snapdragon 600. The screen might be a $20 savings (once again, if they are lucky). Everything else costs the same as the other flagships.
    Reply
  • Impulses - Tuesday, August 27, 2013 - link

    It would've been interesting as a low cost mid-cycle Nexus refresh tho, at like $250-300 (32GB if the latter maybe, with only one SKU)... But then the customization aspect would've been a nightmare (Nexus launches are flaky enough as it is, distribution is not Google's thing) and the theories about Google/Moto's impact on other OEM would've raised hell. Reply
  • BallGum - Tuesday, November 19, 2013 - link

    It's almost more "Nexus" than a Nexus. I think the Motorola phones are almost as though Google tests features before they make it into Android. With 4.4 KitKat the whole thing is a bit more Googley.
    I know this sounds slightly outlandish, but it's explained better over at my Blog:
    http://theballofgum.blogspot.co.uk/2013/11/motorol...
    Reply

Log in

Don't have an account? Sign up now