Moto X Review

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:

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 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:

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:

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:

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.