F2FS is a brand new file system developed by Samsung. The F2FS acronym stands for Flash Friendly File System. It creates an additional layer that improves the performance and life of the flash memory and the overall performance of any system with flash storage. Almost all the Android phones today still come with the old linux ext4 filesystem. This type of file system is not hardware optimized so it is a baseline for performance. There are plenty of benchmarks and tests throughout the web providing evidence of the overall performance improvement of F2FS over ext4 in Android phones. New flagship devices from Huawei, One Plus and many Motorola phones are now using F2FS as stock filesystem. The flagship Moto Z comes with F2FS, sporting a fabulous 1/10 of lag compared to the Pixel XL. However mind that it is a new technology with barely 3 years of development and you might encounter some issues if you try different configurations. But, we are here testing unofficial things, so risk is a known partner. Just keep a safe backup, that is all you need.
Migrating /system has no sense since it is a read only partition (most of the times) and ext4 is faster for pure readings. On the other hand /cache is formatted to ext4 at boot by the kernel. So patching the kernel is the only way to migrate that partition.
Data partition along with the internal storage can be upgraded to F2FS with visible results. Here I share a method to migrate your system without losing any information. The procedure is reversible, so you can return back to the traditional ext4 in case you are not satisfied with the result. The procedure only requires TWRP recovery 3.0.3 and an external sdcard with enough free space to do at least a backup of the data partition. Since we are not modifying boot or system, this procedure is compatible with unrooted systems with locked bootloaders. It is compatible with all the AXON 7 ROMs.
INSTALLATION
1. Reboot to TWRP and perform a backup of your data partition to your external sd (you can't use internal storage since it will be wiped during the process along with the data partition).
2. Backing up your Internal SD card requires a different way. Here I propose 2 options:
2a. If you have an External SD card with enough free space (check that first), you can use it to temporary store the content of the internal sdcard. While in TWRP root menu, go to Advanced / File Manager and browse into the sdcard (You will see the contents of your internal storage). Tap on the checked folder icon on lower right corner. Select Copy Folder. Now browse into the external_sd folder (you will see the contents of yout external SD) and tap the checked folder icon again. Upon confirmation, it will create a folder named sdcard into the external sd with all the contents inside.
2b. If you do not have a micro SD card with enough space then you can use your computer as backup location. From your computer type adb pull /sdcard and all the content of the internal sdcard will be transferred into a folder named sdcard under you current directory in your computer.
3. Now we can safely change the format of the data filesystem. Go back to the root menu of TWRP, go to Wipe / Advanced Wipe and select only the Data partition. Go to Repair or Change File System / Change File System / F2FS. Upon confirmation, the Data and internal sdcard will use the improved F2FS filesystem. If you have an AOSP based ROM such as LOS, RR or AEX among others, then you can do the same to format the Cache partition as F2FS. But do not reboot yet!
4. Go back to the root menu of TWRP and go to Settings. Ensure "Use rm -rf instead of formatting" is set. This will avoid future restores to change the type of filesystem.
5. We can't restore the data at this time since the system won't boot properly with all kernels, the Stock kernel is one of them. At this point it is safer to reboot the system and wait until the Android welcome wizard shows up on the screen. This will setup everything internally.
6. Now reboot to TWRP, go to Advanced > Terminal and enter the commands (you can bypass these commands only if you are using TWRP 3.0.4 or above):
Code:
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /data
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /sdcard
and then without leaving TWRP restore the backup you created in step 1. This will restore your data partition but this time applying an optimized F2FS structure. Do not leave TWRP yet, there is one more step left before booting into the system.
7. depending on the option you used in step 2 you have to follow one of the following options to restore your internal sdcard:
7a. If you used your External SD card for the internal sdcard backup then while in TWRP root menu, go to Advanced / File Manager and browse into the external_sd/sdcard folder. Tap on the checked folder icon on lower right corner. Select Copy Folder. Now while the root directory is listed tap the checked folder icon again. Upon confirmation, it will restore all the backup into the external sdcard back into the Axon 7 internal memory.
7b. From your computer type the following commands:
Code:
adb push sdcard /
adb shell chmod -R 777 /sdcard
This will restore all the backup of the internal sdcard back into the Axon 7 internal memory. All but the empty directories.
You are done!!!! just reboot into the system with the new state of the art F2FS filesystem.
Sometimes the lockscreen information gets corrupted after restoring a backup. Since this process relies on restoring a TWRP backup, chances are that you are experiencing this issue too. In such case please follow the guide for clearing the lockscreen security settings in the AXON 7.
UNINSTALL
In case you want to go back to the initial state with ext4 filesystem in the Data and internal storage just follow these steps:
1. Reboot to TWRP and go to Settings. Ensure "Use rm -rf instead of formatting" is NOT set. This will allow to restore the data partition to the original filesystem of the backup.
2. Follow steps 6 and 7 of the installation instructions, exactly the same way, to restore the Data and internal storage to ext4 with the same contents.
I hope you find this interesting since it is a performance improving method that drains less battery, doesn't involve rooting, doesn't overheat the processors and provides noticeable results. Just let me know if this guide has been useful for you.
NOTE: If you delete Dlavik/cache in the process, please note that rebuilding it is quite fast, less than 5 seconds. This is caused by the cache of the F2FS filesystem, but all processing has to be done. The system will boot after a quick apps initialization but you will see the system somehow a little slow. Leave it for some minutes until all the apps had been completely processed. It is done in the background, but al least you have your system up and running quite fast even after deleting dalvik/cache partitions.
UPDATE (2017-01-20)
If you have already switched to F2FS filesystem without the optimization parameters for TWRP (using TWRP 3.0.3-2 or below with the initial version of this guide), then you just have to enter in TWRP and follow all the steps without leaving recovery:
STEP 1: reboot to recovery and go to advanced / terminal. Type the command df. This will give you the current usage of the partitions. Write down the total 1K blocks, used and available statistics for the /dev/block/dm-0, the partition shared by data and sdcard. You will use these statistics to compare before and after.
STEP 2: Backup of your system (Boot, system and Data) to external SD.
STEP 3: Backup your internal storage (either way of those detailed in the guide)
STEP 4: Format Data and internal storage.
STEP 5: If you are using TWRP 3.0.4 or above then you can bypass this step. Otherwise open the terminal under advanced menu and type
Code:
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /data
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /sdcard
STEP 6: Restore your Data partition.
STEP 7: Restore your internal storage.
STEP 8: Go again to the terminal inside TWRP and type df again to see the difference in the data and sdcard shared partition.
Please let us know your statistics before and after.
Soon this guide will include the final F2FS optimization patch to be used within your system, it will require root, but is that a problem? On the other hand @jcadduono is working on a new version of TWRP using the backported f2fs drivers from Android kernel 4.10 (our stock kernels still use Android 3.18) with the correct optimized mount options. It is still under development but as soon as it was finished, I will update this guide on how to use the new features. Stay tuned!
That's all folks!
Switching to most F2FS doesn't make sense for anything other /cache (which is rarely even used, so probably not worth it) and /data (probably very worth it). The benefits that F2FS related to writing to the partition a lot over time.
There is no benefit to using F2FS for /system over ext4, in fact there are probably downsides. You aren't generally writing to /system very often, so no need to worry about write speeds to it. Read speeds are going to be similar anyway. And unless all the more recent F2FS development is backported into the kernel, you'd be running a very old version of F2FS as well.
I got almost 5000 more score in Antutu just by migrating the data partition from ext4 to F2FS. Writes are slower than reads for almost all the storage systems, and a flash memory is not different. An increase in the write performance is more noticeable than the reduction in read performance. That combination provides an overall increase in performance to the system.
I have been using it in my previous phone for more than 1 year without any issue, however having a stable and updated implementation is in the hands of the kernel developers. recently the Moto-Z uses the F2FS in its data partition with a very effective mount options. Probably this mix of mount options are the trick that makes the Moto-Z the fastest phone regarding filesystem.
jcadduono said:
you can enable it by opening the zip file for the kernel installer and editing patch.d/*-f2fs-fstab
all you have to do is remove the # in front of the partitions you want f2fs added for near the bottom, just below the comment telling you what to do
Click to expand...
Click to collapse
I do not find those files inside the patch.d folder inside the zip file (the minimal kernel patch). I will take the file from the full kernel and I will insert into the minimal patch.
I would like to enable F2FS for the cache partition as well as using the mount options: rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,nobarrier,extent_cache,active_logs=6 for the data partition. It should increase the performance over the current options set. System partition has no reason to be migrated.
I will modify fs_data_opts string definition in the 06-f2fs-fstab file as well as trying to configure cache as a F2FS. If Motorola is using F2FS with successful results, then probably it worths it. I am trying to test whether the solution Motorola did with the Moto Z also works in our device. A deep analysis can be found here.
Oki said:
I do not find those files inside the patch.d folder inside the zip file (the minimal kernel patch). I will take the file from the full kernel and I will insert into the minimal patch.
I would like to enable F2FS for the cache partition as well as using the mount options: rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,nobarrier,extent_cache,active_logs=6 for the data partition. It should increase the performance over the current options set. System partition has no reason to be migrated.
I will modify fs_data_opts string definition in the 06-f2fs-fstab file as well as trying to configure cache as a F2FS. If Motorola is using F2FS with successful results, then probably it worths it.
Click to expand...
Click to collapse
https://raw.githubusercontent.com/o...er/marshmallow/ailsa_ii/patch.d/06-f2fs-fstab
add it to the patch.d folder then. change the data mount flags to whatever you want.
i highly advise against uncommenting system/cache, f2fs is nothing but downsides for them. (incompatibilities for cache, which is unused by OS anyways), system is going to be read only all the time and ext4 has much better inode access/index times than f2fs so clearly better for read only, ex. $PATH reading to find locations of binaries to run, so please don't use f2fs on /system.
rw - lol all filesystems are rw by default
seclabel - this isn't a flag for you to use
nosuid/nodev - somewhat of a safety mechanism, unrelated to performance
noatime - very tiny write performance increase that won't be noticeable
nodiratime - same as noatime, but even less so
discard - i don't believe discard mount option is supported on Axon 7.
acl - acl will reduce performance (that's just extra access control/permission management)
nobarrier - this will increase the performance, yes, and it's probably a good idea because you don't have to worry at all about power outages other than severe kernel panics
extent_cache - this is on by default, so no need to specify it
inline_data - this is also on by default, no need to specify it
inline_xattr - no noticeable changes in performance, but normally specified on android i'd keep it
active_logs=6 - the default is 6, so no need to specify it, and there's no need to change this value (6 is optimal)
background_gc=on - the default is on, so need to specify it....
user_xattr - this isn't actually a valid f2fs flag, it is the default though, and don't specify nouser_xattr on android, it will cause bad things to happen
so....nobarrier is the only flag you should care about adding. no, it won't make a noticeable difference.
read: https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
You can Only go in TWRP then format Data to F2FS and then install the Rom .Have No Problem and all works fine.But cache not work.Every time i Boot android he write it back to Ext4.But data work
jcadduono said:
https://raw.githubusercontent.com/o...er/marshmallow/ailsa_ii/patch.d/06-f2fs-fstab
add it to the patch.d folder then. change the data mount flags to whatever you want.
i highly advise against uncommenting system/cache, f2fs is nothing but downsides for them. (incompatibilities for cache, which is unused by OS anyways), system is going to be read only all the time and ext4 has much better inode access/index times than f2fs so clearly better for read only, ex. $PATH reading to find locations of binaries to run, so please don't use f2fs on /system.
rw - lol all filesystems are rw by default
seclabel - this isn't a flag for you to use
nosuid/nodev - somewhat of a safety mechanism, unrelated to performance
noatime - very tiny write performance increase that won't be noticeable
nodiratime - same as noatime, but even less so
discard - i don't believe discard mount option is supported on Axon 7.
acl - acl will reduce performance (that's just extra access control/permission management)
nobarrier - this will increase the performance, yes, and it's probably a good idea because you don't have to worry at all about power outages other than severe kernel panics
extent_cache - this is on by default, so no need to specify it
inline_data - this is also on by default, no need to specify it
inline_xattr - no noticeable changes in performance, but normally specified on android i'd keep it
active_logs=6 - the default is 6, so no need to specify it, and there's no need to change this value (6 is optimal)
background_gc=on - the default is on, so need to specify it....
user_xattr - this isn't actually a valid f2fs flag, it is the default though, and don't specify nouser_xattr on android, it will cause bad things to happen
so....nobarrier is the only flag you should care about adding. no, it won't make a noticeable difference.
read: https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
Click to expand...
Click to collapse
BIG FAT thanks for the resource. I have a safe backup of the whole system. and I am willing to play the guinea pig role in testing all these options. I already had moved the 06-f2fs-fstab patch into the patch.d folder. But it was late and got some error while flashing. Today I will try again.
Kevinkuensken said:
You can Only go in TWRP then format Data to F2FS and then install the Rom .Have No Problem and all works fine.But cache not work.Every time i Boot android he write it back to Ext4.But data work
Click to expand...
Click to collapse
I have tried to format F2FS and then restore the data and the system doesn't boot. What ROM are you using? So fat I only have tested stock and Z.A.D. ROMs and both exhibit the same behavior.
Im on ZAD Rom and have no Problem to change data to f2fs in TWRP.And Im on Beast Kernel
@jcadduono, I have been trying to add the patched 06-f2fs-ftab file into patch.d folder of your ailsa_ii_xda_safetynet_kcal-1.0 file. But recovery log always returns an error while flashing:
- Executing: 06-f2fs-fstabpatch.d/06-f2fs-fstab: line 2: : not found
patch.d/06-f2fs-fstab: .: line 3: can't open '/tmp/kernel-flasher/patch.d-env '
- Error: Script failed: 06-f2fs-fstab!- Aborting...
Failed to patch boot image!Updater process ended with ERROR: 1
Any clue on what could the problem be?
BTW, I look forward to see your Nougat Kernel!!!!
Thanks for all your help.
Oki said:
@jcadduono, I have been trying to add the patched 06-f2fs-ftab file into patch.d folder of your ailsa_ii_xda_safetynet_kcal-1.0 file. But recovery log always returns an error while flashing:
- Executing: 06-f2fs-fstabpatch.d/06-f2fs-fstab: line 2: : not found
patch.d/06-f2fs-fstab: .: line 3: can't open '/tmp/kernel-flasher/patch.d-env '
- Error: Script failed: 06-f2fs-fstab!- Aborting...
Failed to patch boot image!Updater process ended with ERROR: 1
Any clue on what could the problem be?
BTW, I look forward to see your Nougat Kernel!!!!
Thanks for all your help.
Click to expand...
Click to collapse
You must have somehow removed patch.d-env from the zip at some point, or added a space inside the quotes of . "$env"? I don't know why that error would happen otherwise.
Also, I told you seclabel and user_xattr are not valid f2fs flags, they are display flags only, you won't be able to boot with them.
jcadduono said:
You must have somehow removed patch.d-env from the zip at some point, or added a space inside the quotes of . "$env"? I don't know why that error would happen otherwise.
Also, I told you seclabel and user_xattr are not valid f2fs flags, they are display flags only, you won't be able to boot with them.
Click to expand...
Click to collapse
Finally I was able to flash it. Notepad++ caused the issue. It changed the line end control character and replaced CF by CR+CF. So I just edited it using Sublime and everything went as expected. It flashed properly and the options are in place after reboot. By the way, I removed also seclabel and user_xattr, they are applied by default. I will start doing tests tomorrow.
Happy new year!!!
Cache partition still boot as ext4 after the patched F2FS patch.
I have run AnTuTu v6.2.7 without any overclock at all after applying the F2FS options of the Moto Z. I used my daily drive data with the stock ROM and the repatched patch of @jcadduono to allow F2FS with the extra options.
The AnTuTu score is 152937 Wich makes it the third Android phone in the top 5 list. Adding this patch to an optimized kernel configuration could be close to the iPhone 7 score.
Wow! This phone is a S7 killer!!!
Oki said:
Cache partition still boot as ext4 after the patched F2FS patch.
I have run AnTuTu v6.2.7 without any overclock at all after applying the F2FS options of the Moto Z. I used my daily drive data with the stock ROM and the repatched patch of @jcadduono to allow F2FS with the extra options.
The AnTuTu score is 152937 Wich makes it the third Android phone in the top 5 list. Adding this patch to an optimized kernel configuration could be close to the iPhone 7 score.
Wow! This phone is a S7 killer!!!
Click to expand...
Click to collapse
Dude, I get 152K with B29 stock OS
XblackdemonX said:
Dude, I get 152K with B29 stock OS
Click to expand...
Click to collapse
Even when using the same device, there will be people with more and less performance with stock OS using ext4. It will depend of the bin of the processor, the temperature (thermal throttling), the set of apps you have installed running in background, etc. The important number is the score difference between ext4 and F2FS, in my case it was 7657 points after the F2FS options patch.
Thanks for sharing this. I was under the impression that the stock kernel didn't support f2fs fully for some reason.
I am trying to optimize the filesystem even more. The next step is to provide specific parameters for the geometry with the fs geometry options in the mkfs.f2fs -s- z: these options control number of segments per section and number of sections per zone. Sizes that match chip parameters may speed up FLASH write operations. I assume this should have been taken care of, but I am just trying to find more optimization opportunities within the options.
Does anyone know these two geometry parameters for our eMMC?
@jcadduono Do you know what is the default geometry for mkfs.f2fs partitions in TWRP?
On the options part, I am also considering inline_data and inline_dentry.
Thanks
@Oki
Have you shared with ZTE for inclusion in future updates?
puremind said:
@Oki
Have you shared with ZTE for inclusion in future updates?
Click to expand...
Click to collapse
Nope, I hanven't. But feel free to share this with them if you wish!!!
Happy new year.
I have updated STEP 6 to optimize the initial F2FS structure when restoring the backup. I have also modified jcadduono kernel patch to inject these options also in the kernel to make them permanent. This results in about 3000 extra score in Antutu.