[Benchmarks] File System Performance: F2FS vs EXT4

Search This thread

Androguide.fr

Senior Member
Jul 21, 2012
2,056
7,231
Lyon, France
androguide.fr
I have recently implemented Samsung's Flash Friendly File System (F2FS) into my kernel for the Z1 (Pimped Kernel).

In order to see what this file system really brings to the table I decided to run some benchmarks, in a controlled environment, trying to eliminate as many fluctuation factors as possible.
The methodology is described below.

For this first round, only the /data & /cache partitions were formatted as f2fs, in order to see what kind of improvement we would be able to get out of formatting /system as f2fs too later on.


Benchmarks Used


Methodology
  • Fully wiped and fresh install of the 26/03 CM nightly
  • PA Gapps installed (pa_gapps-modular-full-4.4.2-20140301-signed) & updated
  • Additionnal apps installed:
    • Pimp My Z1
    • Disk Info
    • Benchmark apps

  • No other app active in the background during benchmarks
  • Fresh reboot before running the batch of benchmarks
  • Airplane mode enabled (except for quadrant which requires an internet connection to show the results)
  • Order of the benchmarks:
    • RL Bench
    • Androbench
    • CF Bench
    • 5 minutes pause with powersave governor to cool down the device
    • 0xBenchmark
    • AnTuTu
    • Quadrant

  • Pimp My Z1 Settings:
    • CPU Governor: performance (in order to eliminate differences due to frequency scaling, as this governor just stays at max freq all the time).
    • GPU Governor: performance
    • GPU Max Freq: 600MHz
    • Intelliplug: disabled
    • Dynamic Fsync: enabled
    • I/O Scheduler: FIOPS for both emmc & sdcard
    • Readahead: 1024kb for both emmc & sdcard
    • Entropy contribution: disabled for both emmc & sdcard
    • PowerSuspend: disabled
    • KSM: enabled, 512 pages-to-scan, 500ms timer
    • Thermal throttling: disabled


Disk Usage
One thing I noted is that F2FS has a much higher usage of the /cache partition than ext4, which is to be expected coming from a log-based file system such as F2FS.
As you can see in the screenshots below (ext4 on the left & f2fs on the right), only 4mb out of the 192mb /cache partition is used by ext4, while f2fs uses 68% of that same partition with 114mb used.
Another thing to note is that under f2fs, the reported size of the /cache partition is apparently 2mb larger than on ext4, with 198mb.

EXT4 / F2FS
mc8lrOb.png
Ld2vPEo.png




1. RL Bench
RL Bench is an SQLite benchmark, it only tests database read/writes with various SQL commands in various amounts.
As we can see in the results below, f2fs trumps ext4 with an overall time of only 14.417 seconds versus the 21.403 seconds of the latter.

EXT4
CUDOMRF.png
4YBS5j1.png
RPfmnzH.png


F2FS
zYQQsqI.png
4DdTeDX.png
8pdfAjX.png




2. Androbench
Androbench is supposedly an all-around I/O benchmark.
On this one, the results were so incredibly appart that I think we can safely assume a big part of these results are due to poor coding on the benchmark side.
Still, if we believe the results, f2fs provides slightly slower reads (51mbps vs 66mbps) but over 120x faster sequential writes & 300x faster random write speeds!
I had to reboot and run it a second time to make sure this wasn't an error, but the second run results were even a bit better, as you can see in the screenshots below.

EXT4
IAJHMtR.png
Cav0Cxi.png


F2FS
1st Run
CNFIigd.png
qursk3Z.png


2nd Run
Q9p7gat.png
pLiQdMw.png




3. CF-Bench
CF-Bench is an overall benchmark by Chainfire which measure everything except graphics.
Here again, f2fs is the winner with a better overall score.
That being said, the native writes are a little inferior to the ext4 native write score with 529 vs 535, but has a higher native read score with 996 vs 913.

EXT4
1CZi92F.png
tjLXKhv.png


F2FS
2a1ryPo.png
rMBeY1J.png




4. 0xBenchmark
This reliable open-source benchmark by 0xlab is an overall benchmark used by the Linaro android team during their famous toolchain demonstration.
It has the advantage to output the results in text, xml and json, which you can download below.

On the SunSpider javascript benchmark run, f2fs gets a better score with 744.5ms vs 792.0ms for ext4.
Strangely, on Linpack, ext4 gets a better score with 156mflops/s vs 122mflops/s for f2fs.
On the other hand, Scimark2 reports better mflops/s scores for f2fs in all 6 of its tests, as seen below:

EXT4 Scimark2
Results in Mflops/s
Code:
Scimark2
------------------------------------------------------------
Composite:
  191.7992650532917
Fast Fourier Transform:
  121.33004358991259
Jacobi Successive Over-relaxation:
  431.85904395507
Monte Carlo integration:
  10.79962368351458
Sparse matrix multiply:
  132.34248411160723
dense LU matrix factorization:
  262.6651299263541

F2FS Scimark2
Results in Mflops/s
Code:
Scimark2
------------------------------------------------------------
Composite:
  195.01022812596952
Fast Fourier Transform:
  125.55719947408143
Jacobi Successive Over-relaxation:
  436.3575761486842
Monte Carlo integration:
  11.192272530363814
Sparse matrix multiply:
  138.67117163604067
dense LU matrix factorization:
  263.27292084067756

EXT4 full results: http://d-h.st/iER
F2FS full results: http://d-h.st/iOf



5. AnTuTu Benchmark
No need for an introduction, it's probably the most popular benchmark these days.
On this one again, f2fs is the clear winner with a difference of over 1200 points.

EXT4
HHSOgqE.png
UhhBE6W.png


F2FS
38nH1mB.png
vcsyJrq.png




6. Quadrant Benchmark
Another overall mainstream type of benchmark.
F2FS wins on this one too, with an advantage of 1100+ points.

EXT4 / F2FS
naENUUR.png
Rff1SQv.png





Conclusion, F2FS actually is an improvement over Ext4 for flash devices, and considering its very young age it will most likely be improved over time.
 
Last edited:

Poesini

Senior Member
Apr 11, 2012
764
206
Cali
How are you getting 600 Mhz on the GPU?

I have

PHP:
[email protected]:/sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0 # cat gpu_available_frequencies
450000000 389000000 320000000 200000000 27000000 320000000 320000000 200000000 200000000 
[email protected]:/sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0 # echo 600000000 > max_gpuclk
[email protected]:/sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0 # cat gpu_available_frequencies
450000000 389000000 320000000 200000000 27000000 320000000 320000000 200000000 20000000
[email protected]:/sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0 # cat max_gpuclk
450000000

And its still showing 450 on Pimp and Trickster :(
 

Androguide.fr

Senior Member
Jul 21, 2012
2,056
7,231
Lyon, France
androguide.fr
How are you getting 600 Mhz on the GPU?

I have

PHP:
[email protected]:/sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0 # cat gpu_available_frequencies
450000000 389000000 320000000 200000000 27000000 320000000 320000000 200000000 200000000 
[email protected]:/sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0 # echo 600000000 > max_gpuclk
[email protected]:/sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0 # cat gpu_available_frequencies
450000000 389000000 320000000 200000000 27000000 320000000 320000000 200000000 20000000
[email protected]:/sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0 # cat max_gpuclk
450000000

And its still showing 450 on Pimp and Trickster :(
You're probably just not running Pimped Kernel, otherwise you'd have 389 & 600 too.

EDIT: weird, you do have 389, but not 600.
 
Last edited:

Androguide.fr

Senior Member
Jul 21, 2012
2,056
7,231
Lyon, France
androguide.fr
I am running Pimped Kernel and I have reflashed it also (I have /cache and /data with f2fs)

That's really weird. Which rom are you running ?
I'm also running the last F2FS build and here's my output :
Code:
cat /sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0/gpu_available_frequencies
600000000 533333000 487500000 450000000 389000000 320000000 320000000 200000000 200000000

You have some messed-up steps, too, the 270MHz shouldn't be there, and certainly not after a 320MHz step, that's really weird.
 
Last edited:

mnickkk

Senior Member
Mar 27, 2011
63
5
Some more information:

Beyond the anecdotal evidence above that f2fs has data integrity issues, I can now personally confirm that f2fs is far poorer than ext4 at data integrity.

In the process of bringing up omni, a bug was causing frequent reboots of the device during bootup. This caused a large number of "ghost files" on the filesystem. They would appear if you did "ls *" but spit out an error that they didn't exist. Not good when that happens on your dalvik cache.

These files couldn't be created, nor could their directory entries be deleted. An attempt to run fsck.f2fs would just crash with an assertion error. To fix the issue I had to completely reformat the /data partition. (Not just a typical wipe/factory reset which leaves the "sdcard" contents in /data/media)

With ext4, those files would have been deletable and fsck would've actually done something.
That's pretty worrisome.
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,443
87,747
www.chainfire.eu
I would like to point out that CF-Bench does not take disk reads and writes into account for its final device score for one very important reason:

Android's base Linux kernel (at least when I wrote CF-Bench) does not respect the flag to turn off low-level buffering. As such, the measured results do not reflect actual performance, and it is unknowable how big the unreliability of the results is.

That being said, if one option benchmarks consistently and significantly faster than the other, on the same device with the same setup, then it is likely to actually be faster - you just don't know how reliable the produced benchmark index is, and I certainly wouldn't compare them to scores from other devices.
 

Androguide.fr

Senior Member
Jul 21, 2012
2,056
7,231
Lyon, France
androguide.fr
I would like to point out that CF-Bench does not take disk reads and writes into account for its final device score for one very important reason:

Android's base Linux kernel (at least when I wrote CF-Bench) does not respect the flag to turn off low-level buffering. As such, the measured results do not reflect actual performance, and it is unknowable how big the unreliability of the results is.

That being said, if one option benchmarks consistently and significantly faster than the other, on the same device with the same setup, then it is likely to actually be faster - you just don't know how reliable the produced benchmark index is, and I certainly wouldn't compare them to scores from other devices.
Thanks a lot for the heads-up, that's good to know.
I probably should have taken the time to do at least 4 or 5 runs of each benchmark and calculate the average score in order to get more reliable results.
As you said, I wouldn't give too much importance to these results, but the fact the the f2fs runs came ahead every time is at least a pointer that there is some kind of improvement.

I will do another round of benchmarks with the /system partition in f2fs as well soon, I'll try to do several runs this time around.
Maybe I'll also add this cross-compiled Bonnie++ to the mix (won't do full runs though, just test a few hundred mbs, takes way too long otherwise)
 

Technecium

Senior Member
Oct 6, 2007
1,570
716
Maybe I'll also add this cross-compiled Bonnie++ to the mix (won't do full runs though, just test a few hundred mbs, takes way too long otherwise)

You might have a look at my f2fs tests with bonnie on the Nexus 5. http://forum.xda-developers.com/showthread.php?p=50947848 Posts number 102 & 124

Check out my notes.txt. It is easier to run the tests with the -x switch. Something I learned after the fact.

Also I recommend using bonnie2chart for presenting the test results. If you don't have access to a server you can upload the *.csv files to, I would be happy to process the results for you.

Feel free to pm me
 
Last edited:
  • Like
Reactions: Androguide.fr

->---

Senior Member
Nov 10, 2012
430
81
Wien
That's really weird. Which rom are you running ?
I'm also running the last F2FS build and here's my output :
Code:
cat /sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0/gpu_available_frequencies
600000000 533333000 487500000 450000000 389000000 320000000 320000000 200000000 200000000

You have some messed-up steps, too, the 270MHz shouldn't be there, and certainly not after a 320MHz step, that's really weird.

I am on ext4 and my GPU clocks are also very different from yours. I tried to rewrite the file manually, but RootExplorer want overwrite the file.It was strict read-only. I changed that to rw-rw-r--, but not a chance. Not by creating a new file and copying into the folder, not by editing the original file. I will try to edit the file in the flashable zip and overwrite it hereby.

Edit:
Its in the boot.img, am I right? So no chance to correct it.

Edit 2:
Echo command in console (su) didn't work either.
 
Last edited:

Androguide.fr

Senior Member
Jul 21, 2012
2,056
7,231
Lyon, France
androguide.fr
I am on ext4 and my GPU clocks are also very different from yours. I tried to rewrite the file manually, but RootExplorer want overwrite the file.It was strict read-only. I changed that to rw-rw-r--, but not a chance. Not by creating a new file and copying into the folder, not by editing the original file. I will try to edit the file in the flashable zip and overwrite it hereby.

Edit:
Its in the boot.img, am I right? So no chance to correct it.
Like any file under /sys, it' a sysfs interface, those "files" permissions are handled by the kernel.
What you input into the sysfs interfaces is processed by the kernel, and it usually has safeguards in case the value is too high/low or invalid, same for the permissions, if a sysfs node is defined as read-only then you won't be able to change this unless you recompile the kernel and change this behaviour in the module/driver itself.
Either way you wouldn't be able to just modify it like that, there's a lot more to defining a GPU frequency than just the frequency itself.
This interface is simply here to expose which frequencies are available to userspace.

This isn't related to the filesystem type, I had the same freq table on ext4 before I implemented f2fs in the kernel. Can't seem to figure out what is the cause of this issue, as it seems to be different from a device to another on the same build, and isn't related to the CPU's pvs binning level.

Please keep discussion about this issue in the kernel thread.
 
Last edited:
  • Like
Reactions: Shrukul and olokos

phoenix_rizzen

Senior Member
Aug 10, 2011
903
380
Just curious why you kept dynamic fsync enabled. To test the filesystem itself, and not just the in-memory buffering system, you'd want that disabled, so that writes go straight to the disk ASAP. No?

Still impressive overall. Thanks for testing!

Typos courtesy of my Liquified LG G2 (D803).
 

Top Liked Posts

  • There are no posts matching your filters.
  • 202
    I have recently implemented Samsung's Flash Friendly File System (F2FS) into my kernel for the Z1 (Pimped Kernel).

    In order to see what this file system really brings to the table I decided to run some benchmarks, in a controlled environment, trying to eliminate as many fluctuation factors as possible.
    The methodology is described below.

    For this first round, only the /data & /cache partitions were formatted as f2fs, in order to see what kind of improvement we would be able to get out of formatting /system as f2fs too later on.


    Benchmarks Used


    Methodology
    • Fully wiped and fresh install of the 26/03 CM nightly
    • PA Gapps installed (pa_gapps-modular-full-4.4.2-20140301-signed) & updated
    • Additionnal apps installed:
      • Pimp My Z1
      • Disk Info
      • Benchmark apps

    • No other app active in the background during benchmarks
    • Fresh reboot before running the batch of benchmarks
    • Airplane mode enabled (except for quadrant which requires an internet connection to show the results)
    • Order of the benchmarks:
      • RL Bench
      • Androbench
      • CF Bench
      • 5 minutes pause with powersave governor to cool down the device
      • 0xBenchmark
      • AnTuTu
      • Quadrant

    • Pimp My Z1 Settings:
      • CPU Governor: performance (in order to eliminate differences due to frequency scaling, as this governor just stays at max freq all the time).
      • GPU Governor: performance
      • GPU Max Freq: 600MHz
      • Intelliplug: disabled
      • Dynamic Fsync: enabled
      • I/O Scheduler: FIOPS for both emmc & sdcard
      • Readahead: 1024kb for both emmc & sdcard
      • Entropy contribution: disabled for both emmc & sdcard
      • PowerSuspend: disabled
      • KSM: enabled, 512 pages-to-scan, 500ms timer
      • Thermal throttling: disabled


    Disk Usage
    One thing I noted is that F2FS has a much higher usage of the /cache partition than ext4, which is to be expected coming from a log-based file system such as F2FS.
    As you can see in the screenshots below (ext4 on the left & f2fs on the right), only 4mb out of the 192mb /cache partition is used by ext4, while f2fs uses 68% of that same partition with 114mb used.
    Another thing to note is that under f2fs, the reported size of the /cache partition is apparently 2mb larger than on ext4, with 198mb.

    EXT4 / F2FS
    mc8lrOb.png
    Ld2vPEo.png




    1. RL Bench
    RL Bench is an SQLite benchmark, it only tests database read/writes with various SQL commands in various amounts.
    As we can see in the results below, f2fs trumps ext4 with an overall time of only 14.417 seconds versus the 21.403 seconds of the latter.

    EXT4
    CUDOMRF.png
    4YBS5j1.png
    RPfmnzH.png


    F2FS
    zYQQsqI.png
    4DdTeDX.png
    8pdfAjX.png




    2. Androbench
    Androbench is supposedly an all-around I/O benchmark.
    On this one, the results were so incredibly appart that I think we can safely assume a big part of these results are due to poor coding on the benchmark side.
    Still, if we believe the results, f2fs provides slightly slower reads (51mbps vs 66mbps) but over 120x faster sequential writes & 300x faster random write speeds!
    I had to reboot and run it a second time to make sure this wasn't an error, but the second run results were even a bit better, as you can see in the screenshots below.

    EXT4
    IAJHMtR.png
    Cav0Cxi.png


    F2FS
    1st Run
    CNFIigd.png
    qursk3Z.png


    2nd Run
    Q9p7gat.png
    pLiQdMw.png




    3. CF-Bench
    CF-Bench is an overall benchmark by Chainfire which measure everything except graphics.
    Here again, f2fs is the winner with a better overall score.
    That being said, the native writes are a little inferior to the ext4 native write score with 529 vs 535, but has a higher native read score with 996 vs 913.

    EXT4
    1CZi92F.png
    tjLXKhv.png


    F2FS
    2a1ryPo.png
    rMBeY1J.png




    4. 0xBenchmark
    This reliable open-source benchmark by 0xlab is an overall benchmark used by the Linaro android team during their famous toolchain demonstration.
    It has the advantage to output the results in text, xml and json, which you can download below.

    On the SunSpider javascript benchmark run, f2fs gets a better score with 744.5ms vs 792.0ms for ext4.
    Strangely, on Linpack, ext4 gets a better score with 156mflops/s vs 122mflops/s for f2fs.
    On the other hand, Scimark2 reports better mflops/s scores for f2fs in all 6 of its tests, as seen below:

    EXT4 Scimark2
    Results in Mflops/s
    Code:
    Scimark2
    ------------------------------------------------------------
    Composite:
      191.7992650532917
    Fast Fourier Transform:
      121.33004358991259
    Jacobi Successive Over-relaxation:
      431.85904395507
    Monte Carlo integration:
      10.79962368351458
    Sparse matrix multiply:
      132.34248411160723
    dense LU matrix factorization:
      262.6651299263541

    F2FS Scimark2
    Results in Mflops/s
    Code:
    Scimark2
    ------------------------------------------------------------
    Composite:
      195.01022812596952
    Fast Fourier Transform:
      125.55719947408143
    Jacobi Successive Over-relaxation:
      436.3575761486842
    Monte Carlo integration:
      11.192272530363814
    Sparse matrix multiply:
      138.67117163604067
    dense LU matrix factorization:
      263.27292084067756

    EXT4 full results: http://d-h.st/iER
    F2FS full results: http://d-h.st/iOf



    5. AnTuTu Benchmark
    No need for an introduction, it's probably the most popular benchmark these days.
    On this one again, f2fs is the clear winner with a difference of over 1200 points.

    EXT4
    HHSOgqE.png
    UhhBE6W.png


    F2FS
    38nH1mB.png
    vcsyJrq.png




    6. Quadrant Benchmark
    Another overall mainstream type of benchmark.
    F2FS wins on this one too, with an advantage of 1100+ points.

    EXT4 / F2FS
    naENUUR.png
    Rff1SQv.png





    Conclusion, F2FS actually is an improvement over Ext4 for flash devices, and considering its very young age it will most likely be improved over time.
    14
    I would like to point out that CF-Bench does not take disk reads and writes into account for its final device score for one very important reason:

    Android's base Linux kernel (at least when I wrote CF-Bench) does not respect the flag to turn off low-level buffering. As such, the measured results do not reflect actual performance, and it is unknowable how big the unreliability of the results is.

    That being said, if one option benchmarks consistently and significantly faster than the other, on the same device with the same setup, then it is likely to actually be faster - you just don't know how reliable the produced benchmark index is, and I certainly wouldn't compare them to scores from other devices.
    7
    My analysis

    I did a very similar analysis wasting like 10 hours of my life.. here are my results if anyone is interested https://www.dropbox.com/sh/tkh2jalgz2zitch/AACDJKIL82aRAZjenV05a_ywa?dl=0
    4
    D
    Deleted member 6870501
    The hate for f2fs is cringe worthy. The main purpose of the file system is to provide even wear levelling and use flash storage to its advantage using logs. This not only increases random write and read performance; it extends the life of your flash storage, and most importantly it retains the read/write performance longer due to even wear.

    If any of you f2fs naysayers took the time to research what the file system does rather than look at benchmarks you'd know this.

    Apps that store data and use the cache frequently like Instagram and Google maps benefit greatly from this. Having /system formatted as f2fs would also benefit magisk users due to the constant installing and updating the /system partition temporarily upon each boot, unfortunately many roms still lock /system to ext4.

    I run f2fs on my 1TB mushkin SSD on my custom built desktop PC running fedora silverblue. The performance difference is huge on kernel 4.0 and up, due to the greater capabilities f2fs can take advantage of. This is true for Android as well.
    4
    I did a very similar analysis wasting like 10 hours of my life.. here are my results if anyone is interested https://www.dropbox.com/sh/tkh2jalgz2zitch/AACDJKIL82aRAZjenV05a_ywa?dl=0

    Unless I am not seeing something, with the exception of a few mb faster read speed, all other parameters are lower in F2FS, including performance, which in my book translates to horrible. And it is not surprising. All major file systems have been created and maintained by Linux (about 85%) and Microsoft (the rest). Compare that with Samsung. Granted, they make some good electronics, but in no way they can have expertise and experience to mach the first two.

    So, if anyone wants to go through some trouble to move to F2FS and as a result degrade his device performance, then I guess it is worthwhile... :)

    P.S. I know some may claim "amazing" speeds after going to F2FS, but I bet you can get the same "amazing" speed if you reformat all partitions and SD cards in ext4 and start anew without remnants of your prior roms...