[Magisk] arter97:
I thought “Niko Schwickert” was actually the developer of FDE.AI, given how he personally messaged me with to defend all tweaks and being an admin from your channel. He calls me a racist when I don’t even know what his or your race is. Kinda tells you a lot when that kind of a person is an admin of a group.

But if you’re gonna argue that he’s not a representer of yours, fine.

I see a lot of crap from relatively small and minor developers, but I don’t go after them. However, you’re a public figure with a massive cult-like following. If you’re gonna tell me to censor my thoughts for a public figure, no thanks.

You seems to be missing my point.

I’m fine with that too as long as you know what you’re actually doing. And I proved that you don’t.

See?

Here’s another problem that I mentioned.

What makes you think that applying a certain value to all of the devices is a good idea?

You’re using a value from 2011 for all devices here without even checking the existence or validity of that sysfs node.

Again, another proof that you not doing your research.

https://www.kernel.org/doc/Documentation/scsi/sd-parameters.txt

If there were no performance impact, why do you think SCSI kernel developers put that into the configuration to begin with?

And why do you think that “fixes” rare deep-sleep issues? Did you go into the details as to why it fixes that particular issue?

Back up your statement with scientific data relevant to Android.

I/O merges in the elevator is designed to help slower backing-storage devices.

Again: “Back up your statement with scientific data relevant to Android.”

If you’re just gonna run AndroBench and conclude that it’s faster, that’s still not good enough as it’s not representative to Android’s UX performance. Quite often, it goes the other way around.

No, you did not.

f2fs’ fsync_mode=nobarrier was added in May 2018: https://git.kernel.org/pub/scm/linu.../?id=d6290814b018aa9a81163b4c806935b315041833

Your “v.1.1-rel” from July 2017 includes it:

arter97@arter97-x1:/tmp/FeraDroid-Engine$ git log -1 @
commit f05275e7ed01827d34cd8d7947aa17f71796b1a4 (HEAD)
Author: FeraVolt <fera.volt@gmail.com>
Date: Sat Jul 22 17:49:07 2017 +0600

Merge to v.1.1-rel
arter97@arter97-x1:/tmp/FeraDroid-Engine$ git grep nobarrier
system/engine/feradroid.sh: $B mount -o remount,noatime,nodiratime,nobarrier,discard "${x}";
system/engine/gears/io.sh: $B mount -o remount,noatime,nodiratime,nobarrier,discard "${x}";

You’re still having no idea what that flag does.

FTLs can write data in OoO(Out-of-Order), this is not a faulty UFS firmware behavior. Writer barriers enforces its behavior so that orders can’t be mixed up while writing critical data such as journals. Your bricked users proved to you that it can very well go outside of userdata partition to screw up other partitions.

I pointed those out to prove that you’re not doing the basic researches into changing the kernel values and understanding its ramification.

Your defences aren’t good either, you’re basically saying “Thanks”, “Will check” or “My bad” and just straight up lied about mixing up fsync_mode=nobarrier and nobarrier.

If that’s still not an indication of you not doing your research, I don’t know what is.

And dear forum moderator before censoring my post, please try to understand both his and my points and think whether posting an “un-researched tweak that changes 150 values inside the kernel” is acceptable in XDA.