[Xiaomi Poco F1 ROMs, Kernels, Recoveries, & Other ] arter97:
There are soooo many misinformation regarding f2fs, but I don’t blame you. f2fs documentation sucks and there’s not much details on the internet except for its original paper.

Here’s a discussion that went on a Telegram group. I’m sharing it here to correct some misconceptions regarding f2fs.

No, those “invalid segments” generated from f2fs is not used as a cache in its lifetime. It’s a thing on LFS(Log-structured File System). LFS gives a lot of advantages to flash storage but the growth of invalid blocks is the biggest downside of LFS design. f2fs aimed to effectively solve this via GC.

It NEVER results in data corruption, it just causes a hit on write performance after free segments are gone. Then, GC must be triggered on every write requests.

I’m not sure I’d use “little slow performance” here, it’s quite the contrary. f2fs’ background GC detects idle time to run GC, which is by default set very conservatively to avoid any performance degradation when I/O request spikes while GC is running.

My rapid GC disables background GC because it’s enough to clean-up invalid segments.

Traditional Linux I/O benchmarks don’t represent daily Android I/O workloads. Android I/O workloads are VERY different from traditional desktop/laptop’s workloads.

The ability to turn off journaling safely in SQLite is so far the biggest advantage f2fs has over ext4. Check the piece I wrote on AnandTech for more details: https://www.anandtech.com/show/13474/the-google-pixel-3-review/2

SSR also allows f2fs to reduce performance regression when the utilization is nearly full. This is indeed, very noticeable. If you compare side-by-side f2fs with ext4 both with more than 80% full, f2fs remains more responsive.

Not sure how much of an improvement you would start call “massive”. The LFS nature of f2fs allows fsync() to bypass barrier without sacrificing integrity, which uplifts the bottleneck in write performance. In practice, this gives about 5-6x improvements in write performance.

Google enforces f2fs on Android Go devices. I think it’s a pretty good indication of “everyone is starting to use it”.

I’m not gonna sugarcoat it. You’re correct.

f2fs used to run into funky issues when a corner-case workload’s been thrown at it(which I’m yet to see in the recent year).

But I’m genuinely curious why the heck people are saying f2fs is unstable for regular Android users to use it. I would LOVE to see some real data and fact behind someone saying f2fs is unstable.

You won’t run into corner-case when you’re running Android. If any, it should be better than ext4 to its LFS nature.

btrfs aims to throw you every functions a file-system could possibly offer, which is why people say it’s unstable. btrfs/zfs is not comparable to f2fs.

Totally incorrect. Journalling itself gives ext4 a disadvantage about 30% over f2fs and its GC shenanigans. This is the main reason why f2fs is enforced on Android Go devices.

Well if you’re gonna compare f2fs to ext4 without journalling, you don’t deserve to know these details.

What’s wrong with Pixel 3’s f2fs? I’m yet to see an issue caused from f2fs instability.

Isn’t qcom’s implementation of ICE a mess anyways. This is not an issue of f2fs. f2fs just exposed multiple issues on qcom’s implementation of ICE.

ICE on f2fs should be good if you have the latest CAF stuffs.