Downloaded the T-Mobile MVNO update as Google Fi is a TMobile MVNO. No issues here. Thanks

Downloaded the T-Mobile MVNO update as Google Fi is a TMobile MVNO. No issues here. Thanks
I also am on Google Fi and always use the standard.Downloaded the T-Mobile MVNO update as Google Fi is a TMobile MVNO. No issues here. Thanks![]()
- vbmeta flags for verity/verification disabled (this requires a wipe if you´re coming from stock with those flags enabled), check the FAQ for information on how to do this- vbmeta flags for verity/verification disabled (this requires a wipe if you´re coming from stock with those flags enabled), check the FAQ for information on how to do this
I came from the previous 1. 2.3 January kernel, everything works perfectly.- vbmeta flags for verity/verification disabled (this requires a wipe if you´re coming from stock with those flags enabled), check the FAQ for information on how to do this- vbmeta flags for verity/verification disabled (this requires a wipe if you´re coming from stock with those flags enabled), check the FAQ for information on how to do this
Did you do this?
and when you updated to the Feb patch did you make sure the flags for verity and veritification were still disabled?I came from the previous 1. 2.3 January kernel, everything works perfectly.
Thanks!and when you updated to the Feb patch did you make sure the flags for verity and veritification were still disabled?
In order to run custom kernels, you need to set them flags on EVERY update.
Yeah known issue....I don't think it's even possible for a kernel to cause this issue... But is anyone else having issues with app permissions sticking with this kernel. Issue popped up after flashing.
owh I thought it is a feature? https://developer.android.com/about/versions/11/privacy/permissions#auto-resetYeah known issue....
After rebooting specifiek apps loosing permissions..( behaving same as you just installed them)
Just to clarify as this may sound a bit ambiguous : This is not a kernel issue or related to the kernel.Yeah known issue....
After rebooting specifiek apps loosing permissions..( behaving same as you just installed them)
Thanks for the link!owh I thought it is a feature? https://developer.android.com/about/versions/11/privacy/permissions#auto-reset
I tried that too, it doesn't work.thanks for the helpIn order to run custom kernels, you need to set them flags on EVERY update.
I tried that too, it doesn't work.thanks for the helpand when you updated to the Feb patch did you make sure the flags for verity and veritification were still disabled?
I tried very briefly before updating to Feb. Seems to work well.
no, flash the kernel and forget. Most settings will not stick.Any recommended FKM Settings / Schedules / Tweaks for this kernel?
You don't need to clean install every time. If you have not disabled Verity and Verification a clean install(wipe) is required, however only that first time.Sounds like I need to clean install every time that's way to complicated. Or am I wrong?
"Massive" as in benchmarks. Small in non benchmark scenarios, scoped storage eats up those gains for a lot of apps too.The gains from disabling fsync are massive on every device I've owned capable of having it disabled.
Because Android keeps fsync strictly enabled for very good reasons and it´s harder to disable than on PC. Only a very small number of users actually unlock their phones, and an even smaller number play with fsync.It's my understanding that the whole data loss thing is an event that PCs are sensitive to, at least often enough to where it's been reported to the point where it's spread this far throughout the internet. I've had countless reboots unexpectedly from other issues, experiments, dead batteries etc...over the last 8 years without ever experiencing data corruption...in fact the only issues with unexpected corruption I've had have been due to Google's mutilated updates. Lol. Seriously though.
Yes, there´s the possibility of "dynamic" fsync. That means you might only lose data from when your screen was last enabled and fsync will happen when the screen is off in the best case.It's also my understanding that fsync doesn't have to always be off. If dynamic fsync is introduced, it automatically switches back on when the screen turns off. I'm not arguing or trying to persuade you to do anything that you don't feel comfortable with, but it is honestly the only reason I stopped using this kernel. If anything, I'm just giving my 2 cents in case it interests you enough to look into it a bit more. Thank you for all of your amazing work.
If you find anything interesting about the exynos roots let me know.One last thing...I installed a few Samsung specific, rather Exynos specific kernel managers after digging through the galaxy threads and they expose some more options on our devices such as MIPS Dynamic voltage min/max, and IRQ control. I'm still trying to learn more about Exynos crap because it's foreign to me, so I'm wondering if this could be advantageous.
There´s not much controversy about benchmarks for me. Benchmarks are simply tools for testing very specific scenarios.I knew benchmarks are a controversial topic but I've always liked to pull every bit of performance out of everything I've owned, whether it be a phone, car, my shlong ( couldn't resist) and I've already been able to shut those annoying **** talking Xiaomi Mi10 ultra guys up by dominating 100% of their devices on 3d mark while still not having to charge my phone for 24 hours or keep a fire nearby
Additionally to that filesystems are a lot further than 5-10 years ago, where this idea originates from.Dynamic fsync (the fsync replacement driver faux123 wrote a long time ago) is pretty much dead and causes nothing else than crashes and random reboots on modern / newer versions of the Android adapted Linux kernel.
Maybe what you mean is replacing the default fsync with asynchronous fsync instead?
By reading the instructions in the first post of this thread.
It's not worth it to disable fsync or disable write barriers. The performance gain is nowhere near the benefit of having your data be intact.@Freak07 Any chance you'll implement a toggle to disable fsync?
@Freak07 Any chance you'll implement a toggle to disable fsync?
It's not worth it to disable fsync or disable write barriers. The performance gain is nowhere near the benefit of having your data be intact.
Android is not stable enough to run without fsync, as when Android begins crashing it'll come down hard and not in any graceful manner. When things start going awry there is no way to easily sync, there is no guarantee that the battery can sustain for long enough to sync writes to storage, or that the data can be written without potentially clobbering the file system.
The device is fast enough, the storage speed is fast enough, the penalty for safety is negligible.
All a toggle does is guarantee a user will enable it for "free performance." It's not free.
You pay the safety tax on your data, because if you don't then it only takes one (1) crash for it to be gone.
I formatted my Pixel XL with F2FS and set nobarrier, the performance benefit was only about ~20% on writes, and then it corrupted on the first crash.
It's never worth it.
I couldn´t have said it better myself than @Namelesswonder did.Good points. The only reason I mentioned it is because F2FS is pretty stable now. Honestly, the Android operating system as a whole has matured quite a bit and stability has greatly improved over time.