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
Comments Locked

105 Comments

View All Comments

  • cheinonen - Tuesday, August 27, 2013 - link

    4K is a marketing term thanks to Sony and everyone else. In the actual definition, 4K doesn't have a set aspect ratio. A film mastered at 4K is 4096 pixels wide, and the height is totally dependent on the aspect ratio. If it is flat, then it's 4096/1.85 pixels high. If it is scope, it's 4096/2.39 pixels high.

    Sony, LG, Samsung and everyone else are using 4K to mean 3840x2160 pixels for the home. UltraHD is the technical name now (with Rec. 2020) but that was finalized after the 4K horse had already left the barn.
  • Impulses - Tuesday, August 27, 2013 - link

    Kind of ironic, I bet UltraHD sounds catchier or at least more descriptive to the layman... 4K's definitely spreading fast tho.
  • rcpinheiro - Tuesday, August 27, 2013 - link

    You're right, marketing teams are using "4K" incorrectly but at least here in AnandTech I expected writers to use standard names correctly.
    4K is a standard created by Digital Cinema Initiative, it uses JPEG2000 compression and bitrates upto 250Mbps.
    (I agree with use Impulses, for the layperson "Ultra HD" sounds better than the techy term "4K")
  • Krysto - Tuesday, August 27, 2013 - link

    It is a marketing term - an unfortunate one. Because I don't want them to ruin the ratios when they get to that resolution. They should keep the UHD resolution to scale perfectly from 1080p (4x the pixels). If some OEM's decide that to have "real 4k" they need to make the resolution 4kx2k, that would really SUCK!.
  • mike55 - Monday, August 26, 2013 - link

    Brian, what are your reasons for preferring some LCDs over Samsung's OLED panels?
  • Doh! - Monday, August 26, 2013 - link

    I could tell you couple reasons as a long time user of Sammy's OLED panel in my phone but I'm not Brian. Having said that, burn-in is one of the issues for many OLED panels.
  • Impulses - Tuesday, August 27, 2013 - link

    For me, the over saturated colors IMO, not the best for viewing photos, and I've started to view a lot of non-smartphone photos on my phone now that my camera has Wifi/NFC (most current gen Panasonic/Sony do, even Canon's newest DSLR, the 70D).
  • mike55 - Tuesday, August 27, 2013 - link

    It's unfortunate that a lot of manufactures seem to disregard the sRGB color space when it comes to implementing OLED panels in their devices. I'm not sure I would've bought my GS4 if it weren't for the "movie" display mode that gets it somewhat close to the sRGB gamut.
  • comomolo - Tuesday, August 27, 2013 - link

    I'm not Brian either, but I don't care too much about color accuracy on a phone. I do care about something the N9 invented and amazingly nobody else still copied it yet: permanent display of the time and notification icons. That can't be done efficiently with an LCD and its so useful I simply can't understand it took that long to come to Android. Even this MotoX isn't implementing it fully. You still can't just take a look at the phone on the table and know the time or if some new message is in, if there's a missed call or text, etc.

    I haven't seen a single burned pixel on an AMOLED screen (been using Samsung phones for a while, and lots of friends too). Regarding color accuracy, I don't believe the technology itself is responsible for that, but factory calibration. Android might/should allow for user calibration (the same we do with monitors) and make this a moot point.
  • Heartdisease - Wednesday, August 28, 2013 - link

    Well that's strange. My Galaxy Nexus has had burn in for quite awhile and it is getting more pronounced. Turn any amoled 180* from your normal orientation and look where the on screen buttons were. If you don't see it on the rest of the screen your blind.

Log in

Don't have an account? Sign up now