---------- Post added at 11:17 AM ---------- Previous post was at 11:15 AM ----------
How do you create arter97 kernel?
Ask arter.
---------- Post added at 11:17 AM ---------- Previous post was at 11:15 AM ----------
How do you create arter97 kernel?
Yes. Kernel source is in the OP.
Read my question again and again, till you understand
You asked if any have tried to compile the kernel and the answer was yes. If you don't want a yes or no answer don't ask a yes or no question.
arter97 mate. And I don't know, most people use the compiled kernel from arter himself.
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.F2FS is faster than ext4
One of the reasons is the cache files that it generates
Later these files remain as garbage Becoz no use
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.Kernels can enable background Gc flag
Which may lead to a little slow performance
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.F2FS itself just replacing EXT4, in fstab for example, isn't actually that much faster. Many many backend are up on the web to prove it.
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.However, when you use it configured a bit with nobarrier, etc. it can show a decent improvement (still not massive otherwise everyone would be using it).
I’m not gonna sugarcoat it. You’re correct.Finally, it is no where near as stable as EXT4. It may have stabilised across the years but does not compare.
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.You heard of Btrfs before? Well it's considered still pretty unstable and corrupts data.
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.IIRC EXT4 has flags to lower wear and tear too and it's basically meaningless on UFS nowadays.
What’s wrong with Pixel 3’s f2fs? I’m yet to see an issue caused from f2fs instability.I'm saying just because you or even if this entire group didn't have issues with F2FS, that's not gonna give it the title of stable. Just look at Google's PXL3 implementation.
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.F2FS is still missing things such as ICE support officially.
Google used a proprietary implementation of ICE from CAF Partner tag
ICE on f2fs should be good if you have the latest CAF stuffs.With other developers and my opinion I got to the conclusion that while F2FS is still unstable the only reason not to use is cause ICE F2FS isn't very ready yet.