[Nexus 6P Android Development] Lanchon:
NO!!!! I DONT HAVE ANY MISCONCEPTIONS ABOUT HOW F2FS WORKS!! if you think i do, it's probably your ignorance.

NO!!! f2fs is not any faster than ext4 at reading at all, including when using DBs. and you don't need tests for this, it is just obvious if you know how both FS's work. in fact, due to the way f2fs consolidates many -but not all- writes in various logs, the written data can be highly fragmented, causing mostly random reads where ext4 would mostly use sequential reads. thus f2fs can be slower at reading in-place updated files such as DB files.

i don't need to read any articles on f2fs, thank you. i've known how log structured entities such as FTLs and FSs work from way before f2fs existed. and i've also read more than enough on f2fs. that's why i know stuff such as how to create an f2fs FS in a 100MB partition while you believe 1GB is the minimum required size. and btw, i've also taken a look at the code of the FS itself, with the aim of analyzing how complex a project an f2fs resizing tool would be.

regarding your performance snippet, you obviously didn't understand it:

-the DB transactions measured are ALL WRITE operations. as i said before ext4 is as fast or faster when READING sqllite DBs, contrary to what you said.

-writing and reading a big OTA in an empty cache partition is FULLY SEQUENTIAL operation, where ext4 is as fast or faster.

more importantly, we've told you this already, get it through your head:

-CACHE IS NOT USED, so give it up!!! OTAs are not taken on modded phones!!! and who cares if an OTA is a second slower??? (it wouldn't be anyway.)

-SYSTEM IS READ ONLY (and on top, written fully sequentially when flashing!!!), so switching system is brain-dead.

finally please don't draw my attention to any paragraph regarding the number of logs. the ONLY WAY to fit a f2fs in a smaller partition is to reduce the number logs. i never said it wouldn't affect performance! in fact i said... DONT DO IT!!! finally, if you have to know, reducing the number of logs WONT AFFECT PERFORMANCE FOR CACHE no matter what your benchmarks say. cache is erased before each use, so data separation into logs is useless: data is mostly never updated. and this is yet another reason why converting CACHE is brain-dead: writing big files once in empty ext4 partition is every bit as performant as f2fs.

so to sum it up, i'm afraid that the person here with all the misconceptions is you. you can learn from this post or keep your misconceptions, because i won't continue arguing with you. and let me tell you that assuming that other people know less than you do and saying it publicly is doubly disingenuous.

finally, there's more to a file system than benchmarks. I VALUE THE DATA on my cellphone more than i value its snappiness. that is why i've chosen not to use f2fs and i would recommend anybody who values their data to stay on ext4. even if you assume that f2fs has no bugs, there are reasons why data corruption might happen on f2fs and not on ext4. i'll leave you to find out why, and only direct you to ext4's history, a file system that was once bitten by the same issue. that is reason enough for me: until f2fs doesn't implement certain safety features that ext4 has, i'm not running it. also, rom maintainers can implement f2fs in an unsafe manner (yes, many do) because they just copy and paste stuff that was wrong to begin with. so before you use f2fs, check the mount options used in the kernel carefully.