Moto X Review
by Brian Klug on August 26, 2013 1:30 PM EST- Posted in
- Smartphones
- Qualcomm
- MSM8960
- Motorola
- Android
- Mobile
- Android 4.2
- Moto X
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:
| 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 | ||
|
||||||
| 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.
Facebook
Twitter
RSS
105 Comments
View All Comments
smitty123 - Monday, August 26, 2013 - link
" You have to also be close by, Moto X isn’t going to turn on when you’re across a big room, for example. In addition I’ve noticed that for some reason there are some odd false positives."i don't like to feel like my spied on.
So to me it just sounds like we have a new thing to test: the distance at which the phone can hear us.
Not hear the magic phrase, just how far from us it can still hear us with its 3 mics. forget the "it can't understand us" i'm not testing if it can recognize words, i'm just not comfortable knowing if it can record conversations that a human, nsa for example, can understand. with obama going for the warantless conversation recording, let's just say, this isn't a phone i'd want near me.
That old big brother spying thing is here, i think in the interest of privacy, we need to know these things before buying the phone.
i for one will never get an xbox one just for that reason.
good luck but i'm going back to good old rotary phones lol
flyingpants1 - Wednesday, September 18, 2013 - link
All phones can do that, genius.AnnonymousCoward - Tuesday, August 27, 2013 - link
Does the UI have lag between Android menu screens? Is the touch-screen at least as responsive as every Iphone to come out?I'm guessing there's still plenty of UI lag. In the future, UI's will be instant.
eallan - Tuesday, August 27, 2013 - link
It's pretty responsive, I've had some hiccups and frame rate drops though.Honest Accounting - Monday, September 16, 2013 - link
In the general UI or specific applications?Krysto - Tuesday, August 27, 2013 - link
Maybe it got offset by the last-gen AMOLED tech. Here's the thing. If you're going to argue for efficiency, then don't just use an "old panel". Obviously that won't help. You need to use the latest technologies, the most efficient ones, and THEN lower the resolution and the clock speed of the CPU and GPU.So let's say the latest AMOLED is 2x more efficient than the n-1 before it, at the same resolution. But at 1080p (2x more pixels) it uses just as much power compared to the 720p one. Then I want the latest AMOLED with 720p, to benefit from that improvement in efficiency. If I use the old one with 720p, or the new one with 1080p, then I won't see any improvement in battery life.
Same for the CPU and GPU. Let's say Motorola wanted to hit the performance target of S4 Pro, in both CPU and GPU. Great. But to gain extra efficiency, it would've been ideal to use the S800's CPU at 1.5/1.7 Ghz (instead of 2.3 Ghz), and Adreno 330 at half the clock speed (to match Adreno 320's performance).
That's how you get the extra efficiency. We don't really see new phones that are much better in power consumption than last year's models, because the OEM's keep pushing for performance or resolution or whatever, which completely cancels out whatever efficiency gains they might've had.
But this is our fault, too. Because we keep caring about benchmarks and who's e-penis is bigger, to the point where the OEM's have the incentive to cheat on these benchmarks, to get good PR from it.
If we really want to see better battery life, then act like you don't care about performance anymore (because it has gotten good enough anyway), and ask for 2-day battery life (then heavy users might finally get a full day).
Impulses - Tuesday, August 27, 2013 - link
The whole efficiency line on Motorla's part is probably half marketing spin anyway, I'm sure cost and logistics played as large a role into the component selection as efficiency, even features (the active display stuff would've been impossible w/more common LCD displays, etc). At the end of the day, the only phones that have made monumental battery life strides have been their MAXX editions, by just packing a much larger battery... It seems current gen phones often catch up to last gen MAXX phones in one or two tests tho.If they were really trying to go for battery life above all they'd not only sacrifice some performance but some device thickness, and introduce a phone w/a MAXX-like battery as the only SKU w/no smaller battery model below it. I'm surprised more OEMs aren't putting out slightly thicker phones at times w/3,000mAh batteries like Moto, like not even one OEM has...
michaelljones - Tuesday, August 27, 2013 - link
Brian, Anand,I know I'm commenting awfully low in this list to get seen, but I'd like to see a little more love for Windows phone in some of your comparison graphs. Throw in at least a token Lumia please (or more if you like!)?
I'm a happy Windows Phone user (like many I think), but I have no way to quantitatively compare my Lumia 928 to any of the other handsets. With cameras that kick ass, I can't see how they aren't a comparable discussion.
teiglin - Tuesday, August 27, 2013 - link
Two Lumias feature prominently in the camera section, and more are in the full gallery of camera comparison shots. I mean, yeah, Brian clearly knows that Nokia kicks everyone else's cameras in the nuts, and it shows.Beyond that, where do you want to see the Lumias? I don't think Brian ever got a working Windows Phone battery life test because of screen timeout issues (not to mention the absence of precision brightness controls makes it hard to compare to controlled 200 nit settings), so that leaves javascript benchmarks and display quality. I guess those would be nice to see in the appropriate charts.
michaelljones - Tuesday, August 27, 2013 - link
No mention on the screen page of any other Lumia devices and their types or quality of screens, only a host of Androids and a Apple. No CALMAN data.No speaker phone comparisons. The 928 Nokia crows all about the speaker phone for crying out loud. I want to know if it's really that good or if it really sucks that bad comparatively speaking.
No call time and battery tests. The call time is an open freakin phone call for crying out loud. I could have done that on my StarTac in 1997. Also no charge time comparison, despite the fact that there are a half dozen apps in the Windows Store that will measure this.
I believe several of the tests used in the CPU test are browser tests, and run just fine on a Lumia.
Last I knew GFXBench ran on Windows Phone, yet it's nowhere to be seen in the graphs. (maybe it's pathetic, but at least show it). http://gfxbench.com/result.jsp?site=dx
The camera section DOES have some pics from the Lumias, but fails to mention anything about them in the discussion, nor mention that Brian has them and that reviews are coming, etc. etc. other than an oblique reference to how he likes having access to the controls of the camera ala Lumia 1020. (and no mention of how the 1020 mops everything in the photo comparison as has been widely crowed with every other smart ass smart phone before this i.e. iPhone 5). Also no mention if those 1020 pictures are full 45MP or cropped ones.
I'm not asking for a chart that takes away from the phone in question by any means. I'm just asking for a fair and balanced view of the current Windows Phone offering(s) comparatively speaking. WP has it's own benefits and it's own downfalls, and I'd like to see them compared to others in an honest way.
See http://www.notebookcheck.com/Test-Nokia-Lumia-925-... as an example (granted it's in German, but the charts prove my point that these comparos could be a bit more balanced and not 9 Android phones against 1 iPhone and NO Windows Phone)