Hello. Can I ask any of moderators, as an OP author to close this thread until we all figure things out. People are bullying & pouring toxisity here as it's a waste(they even admit this), not a months of work project. "Friendly" XDA.
Thread closed per OP request.Hello. Can I ask any of moderators, as an OP author to close this thread until we all figure things out. People are bullying & pouring toxisity here as it's a waste(they even admit this), not a months of work project. "Friendly" XDA.
I followed. No more even mentioning 'nobarrier' anywhere from my side.Observations from our side.
The major point of contention is Point 6.2. => `nobarrier` flag used to mount the partition. There were reports that certain device series, this flag bricked devices. While there is no concrete evidence / direct relationship, FeraVolt has excluded certain devices from mounting with nobarrier.
Taking that into account, I would suggest FeraVolt make the `nobarrier` mount optional or remove it from his tweak.
As far as other points are concerned, FeraVolt's first rebuttal contained willingness to modify his tweak. And I hope he follows it.
Your warranty is now void.
I am not responsible for bricked devices, dead SD cards,
thermonuclear war, or you getting fired because the alarm app failed. Please
backup your data before flashing it!
YOU are choosing to make these modifications, and if
you point the finger at me for messing up your device, I will laugh at you.
Do everything at your own risk!
What's worst than this is that he was making fun of the module author on xda discord. He said "Imagine being this guy, lol" after posting a photo of feravolt's comment (where he said he's depressed)
First of all, I don't even know him personally, he never contacted me or my friends, advising or pointing on mistakes or whatever. And so I don't understand why he publically offends me & my work.
This is what you should know about his personality first. This type of behavior kinda reminds me YaroST.
1. "But FDE.AI also overrides the manufacturer’s values." - I am OK with that. They provide those tunables for tuning. So why not.
2. Thanks for "smb135x" wakelock info - I will fix this asap.
3. https://github.com/feravolt/FDE-sc/blob/master/fde.c#L1124 > this code is valid for only for 2.6.x kernels (very old devices), and it realy does improve UX a lot since I personally tested that on my 2011's device. For rest kernels this is simply not applied. I might just add kernel version check.
5.1 "dumbest choices for tuning your I/O device" + https://github.com/feravolt/FDE-sc/blob/master/fde.c#L1217 > This code should fix rare deep-sleep issues on older kernels and as per my tests (I do own 2 UFS & 2 MMC devices), does not impact performance. I might add kernel version check before apply here too and/ro simply remove this string.
5.2 Will change that to single hit merge and/or check for storage type, because on slow MMCs this helps a lot in write speed.
5.3 I did researched about this and know what this option do. With my value it showed a better result in benchmarks which may fooled me up. Will research about this more.
6.2 That's true - I mixed this up with f2fs fsync_mode=nobarrier.
[email protected]:/tmp/FeraDroid-Engine$ git log -1 @
commit f05275e7ed01827d34cd8d7947aa17f71796b1a4 (HEAD)
Author: FeraVolt <[email protected]>
Date: Sat Jul 22 17:49:07 2017 +0600
Merge to v.1.1-rel
[email protected]:/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}";
Also nobarrier (in rare cases) could corrupt FS, not physically destroy block. I believe that none of existing FS mount flags can actually physically destroy a block. (Don't mix up with file system corruption)