Related
Hmm
sorry guys. by now, I'm going to stop fixing this, sigh, I'm not good enough to fix this at the moment.
Can not garantee you the safety of this method but hopefully, the fantastic voodoo lagfix is coming.
Let's hope to see it soon!
I'll leave the update.zip here, if anyone who is intersted in this method, feel free.
FILE LINK :
http://www.multiupload.com/DU013PW7LW
Hi
I have made an update.zip which fixes I9000's lag.
The idea is to format the /data partition, which is the same as /dev/block/mmcblk0p2, to the EXT4 or NILFS2 File Systems.
It's worth because, at least, we don't need an external MicroSD card.
### Before getting started... ###
This method can damage your phone, so you should know what you are attempting to do. All risks are on your own. Also, I strongly recommend you to have a nandroid backup.
### It contains... ###
- absolutely pure JM2 kernel but a tiny modification of the ramdisk. It's from JM2 firmware but should be working on every ECLAIR devices. This kernel helps mounting the data partition to be mounted in every booting and the reason why this is nearly identical to the stock is because some people mind using user-built kernels for some reasons.
- an application called "sl4a" which has shell scripts inside named "EXT4_Lagfix.sh", "NILFS2_Lagfix.sh" and "Openvpn.sh".
※It will install the kernel in the process of applying update.zip so you don't need the Odin.
### More information about this kernel... ###
- As I said, the only thing I've modified is the ramdisk. In details, I've put two files, user_init.sh and user_early_init.sh which are from Unhelpful's kernel, and these files are essential for mounting the /data partition.
- The kernel is almost pure, so it uses modules.
- The user_init.sh, user_early_init.sh support user scripts are very useful. You can see the idea in below thread, OP of Unhelpful.
http://forum.xda-developers.com/showthread.php?t=762171
### About the scripts... ###
- If you touch the EXT4_Lagfix.sh script or NILFS2_Lagfix.sh, it will ask you a superuser permission, back up the entire /data folder in your /sdcard directory, and finally, reboot and do the rest works automatically.
- You can go over to the other file system whenever you want, for instance, it can be changed to the nilfs2 while you are using the ext4 FS.
- There also is a script called Openvpn.sh which will insert tun.ko module and this is for the people who want to use openvpn.
### What you need to do is... ###
- Needs busybox installed and rooted
- Make enough space in /sdcard to make the backing up process work properly.
- In order to use NILFS2 FS, a bit of studying is needed.
About nilfs2 binaries and the Gabage Collector.
go to this site
http://www.nilfs.org/
### What I want to say is...###
- I'm not actually a goot developer so the scripts must be very messy. But it works well, at least with my device.
- Unfortunately, I haven't got the going-back-to-rfs script. I'm working on it recently so if you want to restore the all fixes, you need to flash the firmware.
- Quadrant scores : NILFS2 ~ around 1300
EXT4 ~ around 1700
Do you really concern about the score? I don't. The NILFS2 is exactly what I've needed.
### What I MUST say is... ###
- Big thanks to these people!
## Tayutama -- the beautiful sl4a application is from his rom!
## Unhelpful -- used his idea to mount the /data partition. And the NILFS2 as well!
## supercurio -- He's the one who found how to flash kernels from the phone!
Also, I uploaded some useful utils.
- mkyaffs2image / unyaffs
- chcp / lscp / lssu / mkcp / rmcp
Hope this will help you guys.
So what's different between this and the voodoo lagfix? Is the the partition? I know that voodoo ext4 is /dev/block/mmcblk0p4 while this one is /dev/block/mmcblk0p2
Nice dkcldark.
Will you share your method to unpack-repack the ramdisk from a stock kernel ?
Very nice! Great job!
NeoXTC said:
So what's different between this and the voodoo lagfix? Is the the partition? I know that voodoo ext4 is /dev/block/mmcblk0p4 while this one is /dev/block/mmcblk0p2
Click to expand...
Click to collapse
Oh, I've been busy so I couldn't have a look at the voodoo lagfix. I'm gonna check it. It could be the same as mine or much better
mmcblk0p2 is equal to /data partition, BTW.
supercurio said:
Nice dkcldark.
Will you share your method to unpack-repack the ramdisk from a stock kernel ?
Click to expand...
Click to collapse
Why not? To do this, I've done a bunch of experiments and it made me get older, I think. Will write a reply or a new thread very soon.
RyanZA said:
Very nice! Great job!
Click to expand...
Click to collapse
Thanks!!
dkcldark said:
Why not? To do this, I've done a bunch of experiments and it made me get older, I think. Will write a reply or a new thread very soon.
Click to expand...
Click to collapse
Yeah, theorically it's simple, we have the smallest piece of code building the kernel so why should extracting then reinserting the ramdisk difficult ?
And there comes the difference between the theory and the practice
Congrats for your research and the result, i hope your method can be applied to any kernel including a ramdisk!
This is a major breakthrough in our Opensource Toolbox.
So do you recommend NILFS or ext4 for phones with nand disk? Just reading up a bit on nilfs and seems to create lots of checkpoints? Is it good for nand disk to be writing that much?
I'm tempted to try this tonight
NeoXTC said:
So do you recommend NILFS or ext4 for phones with nand disk? Just reading up a bit on nilfs and seems to create lots of checkpoints? Is it good for nand disk to be writing that much?
I'm tempted to try this tonight
Click to expand...
Click to collapse
Personally, I recommend the NILFS2 File system. I've searched some infomations.
NILFS2 is log-structured File System and known that it's suitable for SSD which is based on nand flash. Normally, Flash has a limited read-write times but nilfs2 tries to write to the entire space equally, and has got the smallest removing interval so the NILFS2 file system makes SSD work very nice. And a great Wear-Leveling as well.
Click to expand...
Click to collapse
I'm not a good developer, as I already said on my post, so I'm not sure it'd also be nice for SGS but it sounds good to me. Actually, I'm using NILFS2 and it's bloody fast!
How difficult would this be to adapt to the Captivate variant of the Galaxy S?
dkcldark said:
Personally, I recommend the NILFS2 File system. I've searched some infomations.
I'm not a good developer, as I already said on my post, so I'm not sure it'd also be nice for SGS but it sounds good to me. Actually, I'm using NILFS2 and it's bloody fast!
Click to expand...
Click to collapse
on which firmware do u recommend to use it?
I'm actually on JM6 but tomorrow i want to try the JM7....
(Any battery drain? )
andars05 said:
How difficult would this be to adapt to the Captivate variant of the Galaxy S?
Click to expand...
Click to collapse
It's not difficult at all.
My kernel is originally from Unhelpful's idea so, people who use his kernel will easily be able to do it. All you need is just remove the zImage and redbend_ua files in the update.zip. Every kernel which supports Unhelpful's rules about /system/etc/init.d will be OK. Or, you can simply modifiy the scripts inside.
One more, if you use Unhelpful's kernel, you don't need the modules any more.
Narcissus85 said:
on which firmware do u recommend to use it?
I'm actually on JM6 but tomorrow i want to try the JM7....
(Any battery drain? )
Click to expand...
Click to collapse
Any firmware should be OK. I'm using JM2 at the moment but I'll try the JM7 as well. So as the result, I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7.
And the battery.. I'm sorry I haven't tested it yet since I've got 4 batteries. I'm not bothered by them lol.
dkcldark said:
It's not difficult at all.
My kernel is originally from Unhelpful's idea so, people who use his kernel will easily be able to do it. All you need is just remove the zImage and redbend_ua files in the update.zip. Every kernel which supports Unhelpful's rules about /system/etc/init.d will be OK. Or, you can simply modifiy the scripts inside.
One more, if you use Unhelpful's kernel, you don't need the modules any more.
Any firmware should be OK. I'm using JM2 at the moment but I'll try the JM7 as well. So as the result, I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7.
And the battery.. I'm sorry I haven't tested it yet since I've got 4 batteries. I'm not bothered by them lol.
Click to expand...
Click to collapse
4 batteries? ahah cool i'll test it tomorrow with my only one battery! :>
thanks for ur lagfix..
mmm just another question...my english isnt so good (i'm italian)....with this "I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7." do u mean that u are going to update ur lagfix with another kernel? so another version comes out soon?
thanks...
ivan
dkcldark said:
It's not difficult at all.
My kernel is originally from Unhelpful's idea so, people who use his kernel will easily be able to do it. All you need is just remove the zImage and redbend_ua files in the update.zip. Every kernel which supports Unhelpful's rules about /system/etc/init.d will be OK. Or, you can simply modifiy the scripts inside.
One more, if you use Unhelpful's kernel, you don't need the modules any more.
Click to expand...
Click to collapse
So, I should flash unhelpfuls kernel. I then next remove the zImage and redbend_ua files from the update.zip, install it, and then run the sl4a script?
Narcissus85 said:
4 batteries? ahah cool i'll test it tomorrow with my only one battery! :>
thanks for ur lagfix..
mmm just another question...my english isnt so good (i'm italian)....with this "I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7." do u mean that u are going to update ur lagfix with another kernel? so another version comes out soon?
thanks...
ivan
Click to expand...
Click to collapse
Yes, I am. Will Just come with a new kernel. Every else is the same.
andars05 said:
So, I should flash unhelpfuls kernel. I then next remove the zImage and redbend_ua files from the update.zip, install it, and then run the sl4a script?
Click to expand...
Click to collapse
In order to reuse after modifying the update.zip, you need to sign it again. If you want to use a plain kernel, I can make it which is not a big deal.
dkcldark said:
In order to reuse after modifying the update.zip, you need to sign it again. If you want to use a plain kernel, I can make it which is not a big deal.
Click to expand...
Click to collapse
That would be most helpful! Thanks for your work! I can't wait to test it out on my captivate
Edit:
I figured out how to resign the update.zip. I'm running the sl4a script now. I'll post the results shortly.
Edit 2:
It appears to back up the data partition, but upon reboot its still rfs.
You may want to make some other modifications I've since learn are needed. Specifically, the stock init will overwrite the MBR, removing any changes you've made to the partition table, and will then write some data to mmcblk0p2 if it does not find a valid RFS filesystem. You might not even see anything wrong at first, but with enough reboots, this will eventually corrupt your reformatted /data partition.
The edit I'm using will be in my next kernel release, and is very simple - open the init binary in a hex editor, find the string "/dev/block/mmcblk0" (make sure there's a NULL after the 0 so that it's not a substring of some longer string) and replace the "m" with a NULL. Init will then fail to rewrite the partition table (because it tries to open "/dev/block/", which is a directory). Then you simply need to change the partition table - you can use exactly the same region of the disk, you won't even need to reformat, just remove the existing partition 2 and make a new partition 3 or 4. Partitions 3 or 4 won't be checked by init on reboot.
Unhelpful said:
You may want to make some other modifications I've since learn are needed. Specifically, the stock init will overwrite the MBR, removing any changes you've made to the partition table, and will then write some data to mmcblk0p2 if it does not find a valid RFS filesystem. You might not even see anything wrong at first, but with enough reboots, this will eventually corrupt your reformatted /data partition.
The edit I'm using will be in my next kernel release, and is very simple - open the init binary in a hex editor, find the string "/dev/block/mmcblk0" (make sure there's a NULL after the 0 so that it's not a substring of some longer string) and replace the "m" with a NULL. Init will then fail to rewrite the partition table (because it tries to open "/dev/block/", which is a directory). Then you simply need to change the partition table - you can use exactly the same region of the disk, you won't even need to reformat, just remove the existing partition 2 and make a new partition 3 or 4. Partitions 3 or 4 won't be checked by init on reboot.
Click to expand...
Click to collapse
I really appreciate for this information!! Just wondering about one thing.
Should I replace the "m" to NULL once in "/dev/block/mmcblk0" or its friend "/dev/block/mmcblk0p2" as well?
Unhelpful said:
You may want to make some other modifications I've since learn are needed. Specifically, the stock init will overwrite the MBR, removing any changes you've made to the partition table, and will then write some data to mmcblk0p2 if it does not find a valid RFS filesystem. You might not even see anything wrong at first, but with enough reboots, this will eventually corrupt your reformatted /data partition.
The edit I'm using will be in my next kernel release, and is very simple - open the init binary in a hex editor, find the string "/dev/block/mmcblk0" (make sure there's a NULL after the 0 so that it's not a substring of some longer string) and replace the "m" with a NULL. Init will then fail to rewrite the partition table (because it tries to open "/dev/block/", which is a directory). Then you simply need to change the partition table - you can use exactly the same region of the disk, you won't even need to reformat, just remove the existing partition 2 and make a new partition 3 or 4. Partitions 3 or 4 won't be checked by init on reboot.
Click to expand...
Click to collapse
Yeah more like curios setup.
What needs to be done in order to adapt this to the Captivate?
I deleted the zImage and redbend_ua files and resigned the zip. I tried both of the lagfix scripts included and neither one worked. It backed up /data and rebooted. It doesn't reformat the fs, and it is still rfs. There doesn't appear to be a /system/etc/init.d directory. I'm running Unhelpful's kernel (v1.2).
I'm rooted and have busybox installed.
If only supercurio can adapt your method of editing the ramdisk inside the stock kernel, it would be awesome! As he already knows how to go back to rfs! We would then have a complete fix!
Development continues here: http://forum.xda-developers.com/showthread.php?t=881837
Universal lagfix kernel project.
This project is aimed at multiple audiences.
If you think you're an end user read on.
For lagfix and kernel developers check the second post.
Download, changelog, bugs and other links can be found at the third post.
Credits
ChainFire for the original cf-root initramfs
hardcore for the speedup hacks
nikademus for the compiled jfs utils
neldar for BackLightNotification
newmail for some kernel modules
RyanZA for OCLF and for being helpful
supercurio for Voodoo
ykk_five for being helpful (and for the memory tweaks)
z4ziggy for z4mod
and for everyone else I might have missed. (like myself - I'm an egoist you know... and for all the people that helped the guys I credited above. And for the people who helped the guys that helped the guys credited above. And for XDA of course.)
If you only care about points
OhmygodIcanget2kpointsatquadranttoobadI'vealreadysoldSGSbecauseitonlyhas300MBraminsteadof512asadvertisedandboughtadesirebecauseilikehowitcrapsatmultitouch.
For the rest of the people
What is this about?
This project has multiple aims:
A JPM based kernel with ext4, jfs, tun and BLN support
An init script which supports multiple lagfix schemes
Init.d support (without early script support)
A modified ClockWorkMod that
Has better support for some features of the SGS-I9000
Includes support for rooting the device
Includes support for switching the lagfix schemes
Has some tweaking options
Various additions that might help the other lagfix/kernel developers
How does this work?
Simply flash the kernel to any JPM/JP6 based, unlagfixed ROM. By default it won't apply any lagfix scheme, so you might use it as a simple ROM, with built in ClockworkMod + rooting support. If you have a complete ROM package (with dbdata.rfs and an older csc file (it won't work with some of the newer csc files) ) you can also flash it with the other parts, just replace the zImage in the PDA.tar with the one supplied. The ROM was tested with the original JP6 and JPM ROMs, and with my Multinational 3.0 ROM.
How can I use the extra features?
Reboot your phone to recovery mode. Under "Advanced ULK", there are some new options:
Reboot to download: switches to download mode
Run 2e recovery: Switches to 2e recovery
Install superuser: installs busybox and superuser to the phone
Lagfix options: switch between various lagfix schemes
Tweak options: switch between various startup tweaks
BLN options: Turns BackLightNotification on or off
Reset permissions: Resets permissions to the same state as init does
What are the lagfix schemes?
They are ways on how to format and bind the various filesystems. You can chose how you want to format the partitions (data,dbdata and cache), whether you want to use an extra loop device or not, and whether you want to bind some directories from /data to /dbdata.
There are also 8 included pre-defined schemes:
OCLF: /data stays at rfs, but has an ext2 loop device on top of it
Voodoo: /data is ext4, all others are kept at rfs
JFS Voodoo: /data is jfs, all others are still rfs
No-RFS Standard: /data is rfs+ext2, all other partitions are ext4
No-RFS Advanced: all partitions are ext4
No-RFS Advanced JFS: all partitions are jfs
No-RFS Overkill: turns on all options: everything is ext4+ext2 and /data/data is bound to /dbdata
No-RFS Overkill JFS: turns on all options: everything is jfs+ext2 and /data/data is bound to /dbdata
(If using the overkill scheme using the bind option is dangerous if using too much apps, so you should disable it in the advanced menu.)
Although I used the names OCLF and Voodoo, the ROM is not compatible with any of them, it's just a naming convention I used. Hope RyanZA and supercurio won't mind
Which one should I use?
You decide. OCLF or Voodoo might seem simple but they are actually working great (but for those you can actually use the originals, they are probably much more stable), while NO-RFS Overkill might seem cool, it is clearly an overkill.
What happens after I chose a lagfix scheme?
If the chosen one is different from the active one the kernel will reformat your device the next start. Before reformatting it will create a nandroid backup, reformats the device then restores the data from your backup.
Is this ROM safe
alpha 0.2 means no. Switching between lagfix schemes might break, and data loss (mostly database corruption) can happen if you're using a lot of loop devices. And this kernel isn't thorougly tested anyway.
How to switch to another kernel/ROM
After disabling the lagfix everything should be fine (except for the possible data corruption). You can always flash another complete ROM package over this using Odin, you'll lose all your data however.
I've found a bug
And you'll find more of them. I'll try to collect them and answers to them at post #3
Internal workings.
In this post I'll try to describe how this works, and how it might be useful for other people.
The Kernel uses both the pre-init trick and the bootlogos trick to load up, and do it's stuff. In the pre-init phase it does the following:
initializes the devices
checks the actual state of the partitions, and decides which lagfix scheme is active
checks the config (resides in /system/etc/lagfix.conf), and if they differ runs the converter application
if they don't differ then it starts to mount the devices, and let's init run.
if during the mounting a fatal error occurs, it prints the log, waits for a couple of seconds and reboots the device.
It does the filesystem checks by mounting and checking whether mounting succeded or not. To defend against samsung's init's reformatting, it simply removes the fat.format command.
In the post-init phase it removes some files (mainly the symlinks to busybox, so they won't interfere with the busybox installed on the system). It also reinstalls fat.format, because it might be needed later.
The lagfixer is built inside clockworkmod, which has the following advantages:
Can use nandroid backup
Can use the framebuffer to show the progress (this makes it much easier to debug problems)
Besides the lagfixer there is also a "graphsh" application, which will run a specified command and prints its output to the framebuffer (the reasons for this are the same: it's much easier to debug this way than to check a log file copied to the sdcard). If a fatal error occurs this command is run so the end-user can see some logs. (all of this is still pre-init). The only problem with using the framebuffer is that core android won't boot up properly if the framebuffer was initialized beforehand (it switches to QVGA with overlapped screens... it's actually quite fun to try using android that way). That's why I always reboot after using either 'graphsh' or 'lagfixer', except for recovery modes, because CWM is using the same framebuffer anyway.
The initramfs is "ro.debuggable=1" so if anything happens one can connect to the phone in adb root mode, to check for errors. Adb is enabled by default in both CWM and base android mode. I don't know the drawbacks of using debuggable=1.
CWM was modified in order to be able to handle the various lagfix schemes. If it tries to mount, unmount or format /data,/dbdata or /cache, it asks for the lagfixer to do the actual mount, unmount or format. Therefore if one saves or restores a backup it will always see and use the actual files, and not the loop device file.
There were some other minor modifications, like binding the home button too to the enter key, using /mnt/sdcard instead of /sdcard, and the ability to back up the efs partition too. (/efs won't be restored however).
There is also a small modification in how the updates work. If there is an update, the init will always run samsung's 2e recovery, if not it will use CWM (you can use CWM's menu to run an update using CWM if desired). This is to maximize compatibility with updates.
About the compiled files:
I had a hard time getting the binaries to work, even when compiling in static mode. All of the binaries are either compiled by me using bionic (AOSP), or used from other sources (but they seem to be using bionic too). The main advantage is that the recovery binary is actually only around 700k, but has a working busybox implementation, a working recovery and some other small stuff. The main problem is with the other binaries (mainly with e2fsprogs). If I could cut from the size the whole initramfs might fit into an official kernel, so it could be used by anyone.
Links
Da kernel 0.3 + BLN 2.2: http://forum.xda-developers.com/showpost.php?p=9157498&postcount=738
Da kernel 0.3: http://android.sztupy.hu/dl/Universal_lagfix_kernel_JPM_0.3.tar
Da kernel 0.2: http://android.sztupy.hu/dl/Universal_lagfix_kernel_JPM_0.2.tar
Da kernel 0.1: http://android.sztupy.hu/dl/Universal_lagfix_kernel_JPM_0.1.tar
Source of the modified CWM: http://github.com/sztupy/android_bootable_recovery
Source of vendor/samsung/galaxys: http://github.com/sztupy/android_vendor_samsung_galaxys
Kernel sources I'm using: http://github.com/sztupy/universal_lagfix_kernel
Bionic port of jfsutils: http://github.com/sztupy/android_external_jfsutils
The contents of the initramfs: http://github.com/sztupy/universal_lagfix_kernel_initramfs
Changelog
Version 0.3
- before the lagfix gets applied there are now multiple options to chose from:
-- backup+restore (the original way)
-- backup, but don't restore (this eventualy results in a factory reset)
-- no backup (this also results in a factory reset)
-- go to recovery mode (to debug)
-- erase config file (to get back to the old options)
- the screen glitch in the first screen is now gone (because the kernel got smaller)
- jfsutils are ported to bionic (takes less space)
- there is a new option that will do the same restore permissions run, as the init script does
- I also added a few fixes to the CWM fix_permissions script, although I don't tested them yet (so it might brick the phone)
- Added two more rooting option:
-- the old one simply copyes busybox, superuser and su to the phone and adds symlinks to busybox
-- the new ones will also remove some old toolbox commands, so if you use the shell a lot, they won't interfere. The first mode only removes the base utils, like ls,mkdir,rm or ln
-- the second mode removes every toolbox command that has an equivalent busybox command (like mount, lsmod, rmmod, etc.)
- Adeed an option to get back to 2e recovery from CWM
Remarks
It seems that formatting dbdata as rfs only works, if you use the 512 PIT file (more exacty it only works if you have used the 512 PIT file the last time you've ticked re-partition in odin). This is probably due to the fact thet the 512 and 803 pit files reserve different space for the dbdata and for the system partition (the 803 pit file reserves 40 units less for the dbdata than the 512 pit file)
Version 0.2
- efs is not backed up automatically during lagfixing (but it's still backed up during ordinary backups)
- added jfs support and some more lagfix schemes using jfs
- added backlightnotification support, with the option to turn it on and off
- added startup script tweaks support, with options to turn them on and off
- removed ext2 support for the base mounts (might be put back into later)
- bind now only binds /data/data (should use less space)
- some minor bugfixes relating
Remarks
- If Updating from 0.1 to 0.2: If binds were turned on you have to turn them off before updating. After the update has finished you can turn them back on if desired.
Known bugs
After the lagfix conversion is done the phone reboots and the lagfix conversion starts over again
This means that the conversion took place, but the result is not the same as was desired. You should reboot into recovery mode and remove the config file.
After rebooting I have a lot of FC's - After switching lagfix schemes I have a lot of FC's
This is probably because of a database corruption. Try loading an earllier backup.
Can't download anything from market
Some configurations might have this problem, I'm still trying to find out why this happens.
Can't download some apps, like angry birds from the market
Retry, it should work after a while. If it still fails remove the external sd.
Shutdown fails on some configurations
Until I find a way to hook onto the shutdown script this might happen on more complex configurations (like the NO-RFS overkill)
Can't get back to rfs on /dbdata
Reverting the lagfix on /dbdata only works if you used the 512 pit file the last time you checked re-partition in odin.
I for one am excited
Dan
Can't wait to see this.
I am waiting too ++++
Lol 100% teasing ^^
gingerbread?
shahadat said:
gingerbread?
Click to expand...
Click to collapse
would be a bit early
Fantastic
Testing now on a very stripped JP6...
very interresting i think i will give it a try hehehe
any feedback?
Would it be unsavory to say that I got a little motion in my pants after reading that first post?
Nah, I think we all did
Sounds great! And I'll wait for a few more version points on that alpha before I try it... but I'm tempted!
wonderful,i'll try it
Sztupy is this kernel and method usable with your multilingual rom v3.0?
Thanks
kurudisease said:
Sztupy is this kernel and method usable with your multilingual rom v3.0?
Thanks
Click to expand...
Click to collapse
check first post. Tested with JPM, JP6 and Multinational 3.0
Test drive
I just used it, I had no issue. Everything worked fine and there is no lag at all, still too soon to say it's faster than voodoo though(which I was very happy with). All data is still there and no problem! Im using JP6 with NO-RFS Extended. Quadrant score is ~1900 for anyone that want to know .
looks great! gonna try this
ist it possible to add in that also??
Startup script speed tweaks
http://forum.xda-developers.com/showthread.php?t=813309
I applied the no-rfs advanced fix and everything worked fine. No issues so far.
Thanks!
****** Information *****
I will no longer develop this kernel, for the lack of development on Z4Mod source.
If you like my work you can try this kernels:
DamianGTO Ultimate Kernel
DamianGTO Steam Kernel
You can also try my tweak program:
Damian tweak
I will continue to support this tread so long its needed.
If you want to change kernel you MUST remove all lagfix first.
*****************************************
The kernels I will post here is now based with Samsungs JPX source code.
The Froyo version is 2.2.1. in this source code.
This make a big change in performance on the samsung Galaxy S.
All this kernel I make will have Zmod in them so you can use Zmod app to convert the file system to ext2.
This will make the phone lagfree and the tweak I put in these kernels will improve things and add things that not supported in stock firmware.
The first kernels I have made(DamianGTO_JPX_1A) have this:
345MB Ram.
Optimized kernel tweaks
Alter minfree strict settings.
Deadline schedueler
Support for bootanimation.zip (custom boot animation)
Initramfs from JPY kernel( So it works on all new firmware)
The kernels has two versions. 256HZ and 500HZ versions.
File system:
Ext2
Rfs
The second kernel I have made(DamianGTO_JPX_2B) have this:
346MB Ram.
300HZ
Optimized kernel tweaks.
Cleaned the kernel from unused services.
Alter minfree strict settings.
Deadline schedueler( change some settings to balance it more)
Support for bootanimation.zip (custom boot animation)
Initramfs from JPY kernel( So it works on all new firmware)
File system:
Ext2
Rfs
This kernels is also an app so you can install it without ODIN.
Make sure you are rooted and you have Busybox 1.17 installed.
Always have a backup when you install other kernels if something happens that I cant predict.
If you come from other kernels then these kernels make sure you have flashed original kernel first so you know your phone is okey.
Do to restriction on file size I cant upload it here.
So I put it on freedrive. I hope it will work.
If any have a better way to do it for free i will look into that.
DamianGTO_JPX_1A.apk is the app with both 256HZ and 500HZ kernels.
DamianGTO_JPX_2B.apk is the app with 256Hz, 300Hz and 500Hz kernels.
I will put all kernels and program on my freedrive that i will make now.
All kernels and program I make from now I will put them on my Freedrive.
Downloading from there is easy. Works both on the computer or your phone.
************** OLD NEWS ***************
The base for these kernels is samsungs jpm source file.
So its NOT based on sztupy setup/kernel.
This kernel is NOT affected by the corruption bug that Supercurio did find.
The goal is to have a clean kernel so you can use z4mod app and change the file system. It will also have some tweaks thats useful for all.
It will always be close to stock kernel, so it will be an option to stock kernel.
If you want more tweak and other stuff there is allot of other kernels.
I will make different kernels with different things in them when I do have time to test them out and be sure they are good and stable.
Z4mod has changed they way to do things and I drop old kernels and use the new way.
I also drop all support for different file system.
Ext2 is a fast file system and its stable.
Most of the other file system use to much overhead and is slower or instable.
This make the kernel smaller to
To root the phone use Z4Root(included below)
To change file system use z4mod(included below)
If you have an old kernel from me and you want to upgrade you must
convert back to rtf first.
If you come from an other custom kernel undo all tweaks and lagfix.
Do also flash an original kernel to see your phone will boot up and work.
After that you can flash one of these kernels.
All zImage_z4mod kernels has this:
342MB Ram tweak.
Optimized kernel tweaks.
Hash 3.
File system:
Ext2
Rfs
The different in the zImage_z4mod kernels is the HZ value.
Lower HZ value can make the phone to drain battery less, but can make the phone less responsive.
Higher HZ value can make the phone drain battery more, but can make the phone more responsive.
DamianGTO_v3 kernel has this:
342MB Ram tweak.
Optimized kernel tweaks(more).
Hash 3.
Alter minfree strict settings.
I/O scheduler is deadline.
Support for bootanimation.zip (custom boot animation)
File system:
Ext2
Rfs
To use custom boot animations you need to download a bootanimation.zip and put that in your data/local folder.
you can find bootanimation.zip on this site or you can go to market and look for a program that help you with that.
If you don't want to use the bootanimation.zip you just remove it from the folder and the original boot animation will be used.
I also made a custom kernel for JPU firmware(DamianGTO_JPU_v1).
This IS JPU kernel with tweaks. Its NOT based on the old JPM kernel.
If you need to root you must use this SuperOneClick root.
This JPU kernel is also patched with Z4mod.
But you need to install the latest busybox from market if you want to convert to EXT2 file system.
This kernel also support boot animations.
DamianGTO_JPU_v1 kernel has this:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Support for bootanimation.zip (custom boot animation)
File system:
Ext2
Rfs
DamianGTO_JPU_v2 kernel has this:
If you downloaded this then download V1 or V3. V2 dont work right.
DamianGTO_JPU_v3 kernel has this:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Deadline schedueler.
Support for bootanimation.zip (custom boot animation)
Sdcard fix when mounting it in windows so you can write to it. It will not mount like a CD anymore
File system:
Ext2
Rfs
I have made an app for the DamianGTO_JPU_V4 kernel.
This will flash the kernel WITHOUT odin
Just make sure you are rooted before you use it.
Is you dont get superuser access, restart you phone and make sure you are rooted.
This DamianGTO_JPU_V4 kernel is little more tweak on deadline scheduler.
So it should be smother.
This kernel has:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Deadline schedueler(More tweak).
Support for bootanimation.zip (custom boot animation)
Sdcard fix when mounting it in windows so you can write to it. It will not mount like a CD anymore
File system:
Ext2
Rfs
I have made an app for the DamianGTO_JPY_V1 kernel.
This DamianGTO_JPY_V1 kernel has:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Deadline schedueler
Support for bootanimation.zip (custom boot animation)
File system:
Ext2
Rfs
z4root-1.3.0.apk is to root the phone. use that before you convert the file system.(NEW)
z4mod.0.9.3.apk is to convert file system.
zImage_z4mod_12_01_v1_500hz.zip Is the kernel with 500HZ value.
DamianGTO_v3_300hz.zip is the kernel with bootanimation and 300hz value.
DamianGTO_JPU_v1.zip is the JPU kernel with bootanimation and some tweaks.
DamianGTO_JPU_v3.zip is the JPU kernel with bootanimation, tweaks and usb storage fix.
DamianGTO_JPU_V4.apk is the new kernel with a installer.
DamianGTO_JPY_V1.apk is the new kernel with a installer.
Thanks all that has helped me to sort out problems.
Before you try this kernel out, make sure you have a backup on you system.
How to Install it? =)
borjaag said:
How to Install it? =)
Click to expand...
Click to collapse
Use Odin to flash the kernel. Use only PDA. no pit file and no re-pertion.
Then copy the update file to the sdcard. rename it to update.zip.
Start the phone in recoverymode and applay the update file.
Before do a backup and read about this things if you dont know what it is.
Edit: this was the old way, so read the first post.
why no EXT4?! Thanks.
hacksome said:
why no EXT4?! Thanks.
Click to expand...
Click to collapse
I think ext2 do work better and its faster then ext4.
I can compile a version with ext4 for you if you want that.
I will make support for most filsystem in the new z4mod system when it works good.
Sent from GT-I9000 jpm My own kernel for z4mod and with 341MB Ram
DamianGto said:
I think ext2 do work better and its faster then ext4.
I can compile a version with ext4 for you if you want that.
I will make support for most filsystem in the new z4mod system when it works good.
Sent from GT-I9000 jpm My own kernel for z4mod and with 341MB Ram
Click to expand...
Click to collapse
z4mod should work 100% with EXT2/EXT3/EXT4/JFS filesystems already, as long as support is compiled into the kernel.
So if you use a kernel with support, it should just work.
RyanZA said:
z4mod should work 100% with EXT2/EXT3/EXT4/JFS filesystems already, as long as support is compiled into the kernel.
So if you use a kernel with support, it should just work.
Click to expand...
Click to collapse
True. But i did not enable more support;-)
My point is that the new system is out and i have to make that work.
I have seen a couple of error on that. So i wait to realese that version. Z4ziggy is looking into the errors.
But i did this kernel and using it myself right now and it works great.
Ofcorce i want the new system to work. I spend my time to figure out what's wrong, but i guess i/we will solve that soon.
Sent from GT-I9000 jpm My own kernel for z4mod and with 341MB Ram
Thx for ur great work .
Just flashed it and it seems to work great. Before that I used a normal JPM Kernel with z4mod EXT2 without any kernel tweaks
DamianGto said:
I think ext2 do work better and its faster then ext4.
I can compile a version with ext4 for you if you want that.
Click to expand...
Click to collapse
Thanks!. I am trying out ext2 and it doesn't seem bad
Thanks.
I shall try to get it better and with more system support.
Sent from my GT-I9000 using XDA App
I would like a JPA kernel with ext4 on on all partitions also system. Thanks.
Sent from my GT-I9000 using XDA App
DamianGto said:
The goal is to have a clean kernel so you can use z4mod and use the filesystem you want.
Click to expand...
Click to collapse
Is anyone trying YAFFS/YAFFS2? As far as I know it would outperform EXT4...?
mclad said:
Is anyone trying YAFFS/YAFFS2? As far as I know it would outperform EXT4...?
Click to expand...
Click to collapse
Have not seen anybody use it.
Ext4 is not the fastest system either.
Its safe and better then stock system.
Sent from my GT-I9000 using XDA App
mclad said:
Is anyone trying YAFFS/YAFFS2? As far as I know it would outperform EXT4...?
Click to expand...
Click to collapse
YAFFS2 can't be used on /data since no interface is available. Doesn't seem like it can be done on BML either, because they're a bit freaky. (It probably can be done, I have no idea how you would though, they're non-standard.)
There is no real need though, as YAFFS2 is NOT a fast filesystem. It's filesystem designed to be safe for the underlying media, and performs decently, but it's not EXT2/HFS+/UFS speed. I think. It's hard to test since it is difficult (impossible maybe?) to port.
At any rate, since /data accounts for 99% of disk I/O, it's mostly waste of time...
As to converting over other partitions besides /data, the problem is that stock clockworkmod doesn't detect it then. Going to try work on making a 'smart' clockworkmod that can detect and mount the correct filesystems.
I' am happy with EXT2, its the most fast one and not really unsave. But would be great to have it on all partitions. Or just EXT2 on /data (for speed) and EXT4 on the other partitions
I may be (probably am) WAAAAAY out of my depth here, but you might want to grab sztupy's modified CWM - the one he uses for his ULK. I believe that would achieve the results you desire.
I think...
RyanZA said:
As to converting over other partitions besides /data, the problem is that stock clockworkmod doesn't detect it then. Going to try work on making a 'smart' clockworkmod that can detect and mount the correct filesystems.
Click to expand...
Click to collapse
Well, I will be short on this one:
Ext2 is NOT a good choice, why? No counselling, so in case of a crash, the chance of filesystem is just too big. Certainly since there is no filesystem checking utility... So this IS faster but very dangerous.
Jaffs or any other flash filesystem is a bad idea too, why? Sd does wear levelling in itself, double it and you will not benefit at all. So totally useless. More on this... On google
Sent from my GT-I9000 using XDA App
harrydg said:
Well, I will be short on this one:
Ext2 is NOT a good choice, why? No counselling, so in case of a crash, the chance of filesystem is just too big. Certainly since there is no filesystem checking utility... So this IS faster but very dangerous.
Jaffs or any other flash filesystem is a bad idea too, why? Sd does wear levelling in itself, double it and you will not benefit at all. So totally useless. More on this... On google
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
That is all very theoretical, but in practical usage of EXT2 on my day to day device for months now, I have not had any issues. And this is with deliberately pulling out the battery to try and break it.
The huge need for journaling on spinning media comes from just how unsafe spinning media can be. Flash storage is inherently a lot safer, since it writes in large chunks controlled by the disk controller, rather than playing with magnets. Not to say that it's 100% safe - and no filesystem is 100% safe when crashed - but it's really not a big issue in practice. The speed benefit makes up for any theoretical data safety issues many many times over for me, personally (and there really is a large speed benefit).
Also, e2fsck appears to do a decent job at checking for errors/metadata consistency.
Ahm,
Not really, journals are used to make writes safer, if you interrupt a write, your filesystem will be inconsistent, so you could loose your entire disk. But you are right, it's not as bad as with spinning disks, but I would never recommend it as safe... There is a reason that ext3 and 4 have been developed as successor..
Ps. Sent by my phone so my responses are short..
Sent from my GT-I9000 using XDA App
harrydg said:
Ahm,
Not really, journals are used to make writes safer, if you interrupt a write, your filesystem will be inconsistent, so you could loose your entire disk. But you are right, it's not as bad as with spinning disks, but I would never recommend it as safe... There is a reason that ext3 and 4 have been developed as successor..
Ps. Sent by my phone so my responses are short..
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Not really. Journals are just additional metadata such as 'I am about to write to block X' 'I have finished writing to block X', etc. When the system crashes, this helps the system recover and work out what it was busy doing - it's not a silver bullet that magically stops data loss. If a file was being resized, then without journals the metadata would show that the file had been resized - even though the data inside would be garbage as it wasn't written yet. In the journaled case, it's possible to tell that this has happened, and the file can be deleted instead.
So with journaling you'd end up with the old file, and without you'd end up with a corrupt file. In either case, try not to crash your system, since an out of date file can be bad too (but not as bad as a corrupt one).
At any rate, the actual chances of managing to hit the power at just the right time (between a metadata entry and actual file entry) is VERY slim on the SGS, because the MoviNAND has a capacitor backed operation queue which generally prevents this from happening in many cases.
Improve your One X multi-tasking using this simple and quick script!
User Feedback from this script:
"Nubzori: Thank you so much. After 10mins of testing, loaded bunch of apps, news, twitter, pulse, xda, chrome, clock, task manager, none of these refreshed"
Note: this script only works on roms that support init.d, it's been brought to my attention that init.d is not supported on some stock roms/kernels although it must be said; Why the hell would anyone want a stock rom??
UPDATE 15/06/12 - Thanks to Orical who has advised me this link here is a solution to those having problems with getting init.d scripts to work. This basically gives you the ability to enable init.d scripts in any rom!!!
Steps to installing script - EASIEST METHOD
1. Download this script of your choice and transfer to your phone (using USB cable or download direct to your phone or AIRDROID or whatever)
2. Rename from multitasking.txt to just multitasking (without any extensions) and place this in your /etc/init.d/ or system/etc/init.d (if you cannot see this, make sure your es file explorer is showing hidden files and folders which can be changed within the settings of es file explorer, also you need to make sure you go up to root directory which is again enabled within es file explorer)
3. You must be rooted to access this folder (make sure you set es file explorer to go up to root directory). These scripts alter the minfree values in your lowmemorykiller system module.
4. Once you have moved script file to init.d to mark as executable by clicking on script and setting permissions as executeable within es file explorer.
5. OR Just open the file and you can find several options, one you need is 'linux handler', choose that and next select execute option. It will now executed automatically.
Alternative method of installing script:
adb remount
adb push C:\Users\your name here\Desktop\multitaskingxtremextra system/etc/init.d
adb shell
chmod 644 system/etc/init.d/multitaskingxtremextra
adb reboot
From what I know of, the android system generally handles around about 5/6 apps in memory without any problems, any more apps and then you start getting refreshes, I've tested using LBE firewall (running as service), battery status, firefox with multible tabs open, gmail, messaging, gallery and the sense launcher (as this is an app as well). Any more and it starts recycling ram for some reason and you will get refresh on some apps (depends on which app)
Troubleshooting:
Can't find init.d, here is the answer:
Use the root explorer to copy it to system/etc/init.d
Just open the file and you can find several options, one you need is 'linux handler', choose that and next select execute option. It will now executed automatically.
The default values for the One X are:
STOCK ONE X TEGRA:
8192, 10240, 12288, 14336, 16384, 20480
My multitasking script alters this to:
2560,4096,6144,7680,8704,10240
My multitaskingxtreme script alters values to:
1536,2048,3584,5120,8704,10240
My multitaskingxtremeextra has the xtreme script as well as:
Dirtybackgroundratio 70
Dirty Ratio 90
VFScachepressure 10
And kill oom allocating task 1
my multitaskingultimate has the same as multitaskingextremeextra except the minfree values are more aggressive for the best multi tasking you can get on the one x
512,1024,1280,2048,3072,4096 - this is the best settings I have used for multitasking and have run 6/7 apps and some cases more without refreshing on a full SENSE 4 rom which is impressive if you ask me, the combination of apps where Firefox, Chrome, Gallery, Youtube, Dialer, etc.
You should notice that most apps will not reload when multitasking (except if you are intense gaming such as shadowgun or something intense like riptide), in some cases too many apps running will cause refresh if multi tasking, take note in the fact that htc senses software uses up alot of ram leaving little free as it is for other apps.
If you want to return to default values, simply delete the script from your init.d and reboot your android phone
If this has helped you please hit the Thanks button rather than post thanks!!
My test was using chrome beta, ebay, gallery, file explorer, ebookdroid, whatsapp, gmail, text message and all did not refresh whilst using,
I will also experiment with different scripts & methods and post any alternatives that may further improve multi tasking on the one x.
NOTE: I hold no responsibility should you damage your phone in anyway using this script. However damage is unlikely.
Information:
min free kbytes (vm.min_free_kbytes)
This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a pages_min value for each lowmem zone in the system. Each lowmem zone gets a number of reserved free pages based proportionally on its size. Default is 2048kb.
dirty ratio (vm.dirty_ratio) and dirty background ratio (vm.dirty_background_ratio)
This controls how often the kernel writes data to "disk" (in our case the internal microSD system card, not the removable microSD card). When your apps write data to disk, Linux actually doesn't write the data out to the disk right away, it actually writes the stuff to system memory and the kernel handles when and how the data is actually going to be flushed to the disk. These values represent a percentage, the higher the percentage, the longer it waits to flush, the lower the percentage, the more often flushes will occur. Now remember, we are dealing with solid state storage, not the traditional disk platter and spindle. So we are actually able to delay flushes a little longer with solid state versus a traditional hard drive disk.
VFS Cache Pressure (vm.vfs_cache_pressure)
Now here is where it gets interesting! File system cache (dentry/inode) is really more important than the block cache above in dirty ratio and dirty background ratio, so we really want the kernel to use up much more of the RAM for file system cache, this will increas the performance of the system without sacrificing performance at the application level. The default value is 100, as a percentage, and what you want to do is lower the value to tell the kernel to favor the file system cache and not drop them aggressively.
oom allocating task (vm.oom_kill_allocating_task)(enable or disable, generally in Linux this value is either a "1" or a "0," representing as on or off.)
This enables or disables killing the OOM-triggering task in out-of-memory (oom) situations. If this is set to zero, or disabled, the OOM killer will scan through the entire task list and select a task based on heuristics to kill. This normally selects a rogue memory-hogging task that frees up a large amount of memory when killed. If this is set to non-zero, or enabled, the OOM killer simply kills the task that triggered the out-of-memory condition. This avoids the expensive task list scan, which can take mass amounts of time and "hang" or freeze the system.
This thread would like to thank the following:
rayford85 - for pointing out #!sysbin in script which i stupidly left out and alternative installation method
Nubzuri - for pointing out to those who could not find init.d
rycon33 - for pointing out that init.d not supported on some stock kernels/roms
My MODS
----------------------------------------------------
[MOD] Improve Multi-tasking on HTC One X
----------------------------------------------------
[Currently owned devices]
- HTC One X Tegra 3
- Motorola Xoom
- HTC Sensation
- HTC Desire HD
Thanks a lot, much better multitasking now
Sent from my HTC One X using XDA
i thought it's about time we got something like this and decided to bother modifying the values, it is a noticeable difference!
Would this be the same or similar script to the one in this thread?
http://forum.xda-developers.com/showpost.php?p=26437514&postcount=93
My phone is rooted but I can't find the init.d folder. I have \etc but no init.d. Should I create the folder or just place it in etc?
nope its my own script, for some reason the op hasn't replied back yet about his script so i couldnt test it and decided to make my own, so far it is better than the original minfree on the htc one x tegra 3,
also you need to be using es file explorer make sure you can view all files/folders (including hidden) in settings of es file explorer
Does the phone need to be rooted ?
I downloaded es file explorer and set the hidden file/folder option. I still can't find /etc/init.d
I can see other hidden files and folders in other directories but can't locate init.d
Any ideas?
thanks for this
Thanks for your contribution .
@silentkill @john9 please hit the thanks button and you are welcome,
creepinchi: make sure you have access to your root directory, follow my instructions above in the first post, you need to be able to go up to root directory then you will see etc folder then go into init.d folder then place script here
I don't want to root my machine yet, is it possible to modify the files the other way?
don't you need to make the script executable chmod +X ?
yes executable, sorry forgot to mention this, will update main post
quick question if you/i made this as a cwm zip would you need to Mark it as executable In es?
Sent from my HTC One X using xda premium
I'm not sure I've not really tried, why don't you give it a go
Thanks! Only a quick test but seems much better on my One X. Chrome Beta has gone from reloading every time I dared to leave it to only reloading if I open 5 or so apps. Great job, makes the shiny sense multitasking screenshots seem a bit less silly now
mox123 said:
I'm not sure I've not really tried, why don't you give it a go
Click to expand...
Click to collapse
Will do when I get back on my pc.
Sent from my HTC One X using xda premium
P.m' d you with values.
I am rooted and have show hidden files enabled but still can't find the file. Is this only for the tegra 3 version?
In short, what I will be doing here is mounting the /system partition as file system EXT2. Default is EXT4. The reason for doing this is simple. The /system partition is more of an access database where information is read and never written. The goal here is to remove journaling and not only journaling but the redundancy of the code tree of EXT4 by simply killing the EXT4 journal and leaving it mounted and formatted as EXT4.
EXT4 – The file system uses a function called journaling. Journaling, in short, is a file system log. What this provides to you as the user is a quick method of recovery if there is ever a system failure: unclean shutdown, file corruption, etc. If there is ever a problem, the journal is called and the data is restored with no issues. The cost of this journaling feature, however, is CPU time/usage. CPU cycles are used to write the journal to the disk.
EXT2 – This file system does not use journal. No recovery method, etc. So if something is corrupted, there is no way to recover corrupted files/blocks/data.
What does all of this mean? – Simple. What it means is those of us who are rooted, running a stable ROM/Kernel combo, and using a backup method such as TWRP or CWM, can safely use EXT2 for /system without any worry because all we need to do is make a backup of our /system partition via recovery, tuck it away on our internal SD card and save it for a rainy day - restore it if there is every an unclean shutdown (battery pull, reboot caused by an unstable kernel, etc.).
What benefits will you see/feel?
Honestly, I have no idea at this point. I know for a fact that the device will boot faster and read operations on the /system partition will be absolutely insanely fast. As fast as they can possibly be on the Note 3. As far as “end of the day” battery savings, well, this is kind of the point of me doing this and sharing. I am going to find out, and post my results here so other people can decide if they do or don’t want to do this as well. If all goes well, I’ll edit this post tomorrow with some quick instruction on how to convert the file system. It should be a quick and easy process.
Other benefits of using EXT2 instead of EXT4:
EXT2 is backward compatible with EXT4. What this means is you can have a file system formatted to EXT2, and it can be mounted as EXT4 and it will only utilize the newer useful features found in EXT4 that were not originally present when EXT2 was introduced. When mounted as EXT4, EXT2 will not use journaling, but will use EXT4’s superior block allocation and “tagging” feature. EXT4 has the ability to mark unused blocks on the disk so it knows to not look there for data – this saves precious time in read operations. EXT2 does not have this feature… except when it is mounted as EXT4
The biggest advantage, here, is to get rid of that useless EXT4 journaling feature used on our RO /system and save CPU cycles. We use backups.We are a different breed of users, right? We demand performance and push our devices to the limits and somehow manage to maintain a stable and usable system, correct?
YES! So, we’re gonna go ahead and take advantage of this super awesome backward compatibility of EXT2 on the /system partition and get some positive performance index out of it
INSTRUCTIONS - convert /system to EXT2
1. Unzip the .zip folder of your ROM of choice.
2. Find /META-INF/com/google/android/updater script.
3. Open the updater-script file in a text editor.
Any lines where you see "EXT4" and "system" in the same line, you need to change that 4 to a 2. Only do this for lines with system and EXT4 in the same line.
4. Save the changes, then zip the ROM back up.
5. Place ROM on your internal SD card, then boot into recovery - YOU MUST BE USING TWRP FOR THIS
6. Once you get into recovery, you will see your TWRP options (there are 8 tiles in recovery) - select the one that says "Advanced"
7. You will now see 6 tiles. On the left side, select the one that says "Terminal Command"
8. At the top you should see a / symbol - this is the directory you are going to begin your session in. You want it to be /
9. On the bottom right of the screen, hit "Select"
This next part is very important. Do not mess up.
When you get to the terminal screen, type this command:
Code:
mke2fs /dev/block/mmcblk0p23
DO NOT continue until you have double checked that the number you punched in is 23! I cannot stress this enough. 23.... 23..... 23..... again that last part is "...mmcblk0p23"
After you have verified the correct partition number 23, hit the GO button on the keyboard to execute the command. It will run for a couple seconds and finish up.
After it finishes reformatting, flash your ROM of choice (the one where you edited any lines). When you are done, boot up.
You are now running an EXT2 file system for your /system partition. Welcome to the thunder dome
Cool, can't wait to try, thanks for this finding
Sent from my SM-N900T using Tapatalk
Why not just create and mount an ext4 filesystem with no journal? There is a reason they made the ext4 driver able to mount ext2,3 filesystems. Aside from journaling, which can be disabled, ext4 and it's driver are generally better.
edit - Didn't mean to quote.
muqali said:
Why not just create and mount an ext4 filesystem with no journal? There is a reason they made the ext4 driver able to mount ext2,3 filesystems. Aside from journaling, which can be disabled, ext4 and it's driver are generally better.
edit - Didn't mean to quote.
Click to expand...
Click to collapse
The reason is because the op paths in the file system tree (speaking of EXT4) are optimized for the journal. Without the journal the code path is redundant and the journal-optimized block has empty overhead. EXT2's strength is it's simplicity in structure.
Basically what this translates to is EXT4 formatted disk, mounted as EXT4 and with no journal, is not as fast or efficient as EXT2 formatted disk mounted as EXT4.
I am running this set up right now. This thread will be updated soon with instruction on how to convert it.
Ext4 has quicker read times than Ext2 which too me is going to the biggest perofmance increase.
This sounds interesting, but I think I'll wait to see others' experiences before giving it a go myself. Will be keeping an eye on this thread though.
Sent from my SM-N9005 using XDA Premium 4 mobile app
The only reason EXT4 has faster read times is because of what I just explained - ext4 uses a method of marking unused blocks on a disk, so it doesn't scan them looking for something. EXT2 does not have this feature. However, when an EXT2 formatted disk is mounted as EXT4, it does utilize this feature of EXT4.
Do you have any data, your own or third party to back this up? Do you plan on using an ext2 system with the ext4 driver? Or the old ext2 fs driver? As I understand it, the ext4 driver was given the ability to mount 2/3 filesystems for simplicity sake as well as the newer driver being better but I could be mistaken.
edit - The way you explained it in your last post seems to sound like you'll use ext4 driver on an ext2 fs, I was just asking because I wasn't 100% sure.
muqali said:
Do you have any data, your own or third party to back this up? Do you plan on using an ext2 system with the ext4 driver? Or the old ext2 fs driver? As I understand it, the ext4 driver was given the ability to mount 2/3 filesystems for simplicity sake as well as the newer driver being better but I could be mistaken.
edit - The way you explained it in your last post seems to sound like you'll use ext4 driver on an ext2 fs, I was just asking because I wasn't 100% sure.
Click to expand...
Click to collapse
That was the intention, correct. Using EXT2 formatted /system but mount it as EXT4 - for the reasons I outlined. To effectively remove journaling and not only that, but the redundant overhead of journaling in the fs tree which would still remain if I were to, say, run this command...
Code:
tune2fs -O ^has_journal /dev/block/mmcblk0p23
EDIT** and so far, yes the difference has been noticeable in boot up time - which is a clear indicator of a performance increase. It loads the /system much faster during boot. Battery life has been slightly better as well.
Do you have a video or benchmark showing the differnce?
LancerV said:
Do you have a video or benchmark showing the differnce?
Click to expand...
Click to collapse
A benchmark? People actually use those? lol.
My own device before doing this mod booted in about 21 seconds from the off position. After doing this it was 15 seconds. I full booted it 3 times for each EXT4 and EXT2... it was consistently the same.
You don't need a benchmark to understand there is an obvious performance increase there. Battery life has also been a little better today. My usage on a daily basis is consistently the same with no changing variables. 15 hours off the charger and 75% battery with 1 hour and 30 minutes screen on time is what I typically see. Today I was 15 hours off the charger, 81% battery with 1 hour and 30 minutes screen on time.
CPU cycles have been reduced, obviously.
If you wanna give it a go... You won't regret it. Post your results here so we can compare :highfive:
Nothing wrong with storage benchmarks, hell the best Windows/Linux/Unix storage benchmark is from 2006 and works perfectly. It's pretty much a staple when it comes to setting up Fibre, and 10Gbe SAN's to make sure the throughput you should be getting you are getting and to test various raids in their IO performance along with read/write performance.
So to say lol people still use benchmarks is pretty naive.
LancerV said:
Nothing wrong with storage benchmarks, hell the best Windows/Linux/Unix storage benchmark is from 2006 and works perfectly. It's pretty much a staple when it comes to setting up Fibre, and 10Gbe SAN's to make sure the throughput you should be getting you are getting and to test various raids in their IO performance along with read/write performance.
So to say lol people still use benchmarks is pretty naive.
Click to expand...
Click to collapse
I have not seen one benchmark available on the playstore that is even remotely relevant. What a joke it is to see a tech article running a quadrant test comparing two devices using a benchmark... so, if you were talking about one of those - quadrant, antutu, etc... none of these are going to give me an accurate representation of what kind of performance increase or decrease I am seeing for /system because they don't test those partitions. There are more accurate ways to run a performance test on a disk.... but it's quicker for me to just go ahead and reboot the device since, well, I know what I am doing and happen to be doing it on a portion of the disk where a majority of the work by the CPU is coming from accessing this particular partition of the device.
During boot, there is one task being executed and one task only... booting! Any most everything being loaded is coming from where? /system
Naive? I spent time on Google's team as a software engineer a couple years back... I am far from naive. You are just not looking at this from a practical or logical point of view.
I'll give you an analogy before I go to bed so you can better understand:
If your car runs out of gas, and stops running, and somebody gives you a ride home, then somebody else calls you and says "Hey, I just saw your car on the side of the road, saw your post on G+ about running out of gas. Well, I happened to have a gas can with me and put a gallon of gas in it for you. Go pick it up!"
Now you get a lift back to your car, put the key in, and it starts right up. Do you then turn it off and walk to a gas station, get a gas can, walk back, put more gas in it, and drive away? No, you don't. Because you have already obtained a positive result. There is no need for "testing" at that point. You have clearly established a positive result.
Anyways, benchmarks.... can be useful sometimes. But you are mistaken if you think:
A) They will give me anymore information than I know at this point regarding the test method...
B) I am going to be allocating more time and resources to run a "relevant" test on my /system partition
C) I have not already obtained a clear result
Not trying to sound arrogant... but I've been doing this a while. I'll pass on the benchmarking this time around.
cun7 said:
I have not seen one benchmark available on the playstore that is even remotely relevant. What a joke it is to see a tech article running a quadrant test comparing two devices using a benchmark... so, if you were talking about one of those - quadrant, antutu, etc... none of these are going to give me an accurate representation of what kind of performance increase or decrease I am seeing for /system because they don't test those partitions. There are more accurate ways to run a performance test on a disk.... but it's quicker for me to just go ahead and reboot the device since, well, I know what I am doing and happen to be doing it on a portion of the disk where a majority of the work by the CPU is coming from accessing this particular partition of the device.
During boot, there is one task being executed and one task only... booting! Any most everything being loaded is coming from where? /system
Naive? I spent time on Google's team as a software engineer a couple years back... I am far from naive. You are just not looking at this from a practical or logical point of view.
I'll give you an analogy before I go to bed so you can better understand:
If your car runs out of gas, and stops running, and somebody gives you a ride home, then somebody else calls you and says "Hey, I just saw your car on the side of the road, saw your post on G+ about running out of gas. Well, I happened to have a gas can with me and put a gallon of gas in it for you. Go pick it up!"
Now you get a lift back to your car, put the key in, and it starts right up. Do you then turn it off and walk to a gas station, get a gas can, walk back, put more gas in it, and drive away? No, you don't. Because you have already obtained a positive result. There is no need for "testing" at that point. You have clearly established a positive result.
Anyways, benchmarks.... can be useful sometimes. But you are mistaken if you think:
A) They will give me anymore information than I know at this point regarding the test method...
B) Allocating the time and resources to run a relevant test on my /system partition
C) I have not already obtained a clear result
Not trying to sound arrogant... but I've been doing this a while. I'll pass on the benchmarking this time around.
Click to expand...
Click to collapse
Right on. Great work OP. While EXT2 isnt for everyone. Experienced users can gsin value from using it. Nice Work!!!
Sent from my Samsung Galaxy Note 3 using JellyBombed Tapatalk.
My phone takes about 15secs to boot up not sure Im going to really notice a 1-2sec diffrence, a better analogy would be taking a car that does 0-60 in 6secs and a pos looking car and one that does 0-60 in 6.2 secs and be looking like a sports car. The differnce would be so minuscial that if you asked people which one accelerated faster they would naturally pick the one that looks like a sports car because thats how peoples minds are trained to think sportty looking car = quicker.
Its kinda a mental placebo effect, hence why I asking if you had a boot up video seems like that would be proof enough.
Also ran a top command and suprise system is using 1% and its the top command so I dont see where you are coming up with the extreme cpu cycles you say journaling is causing. Not to mention the fact /system is pretty much only called upon boot. Most other times its going to be pulling r/w cycles from /data or /sdcard.
LancerV said:
My phone takes about 15secs to boot up not sure Im going to really notice a 1-2sec diffrence, a better analogy would be taking a car that does 0-60 in 6secs and a pos looking car and one that does 0-60 in 6.2 secs and be looking like a sports car. The differnce would be so minuscial that if you asked people which one accelerated faster they would naturally pick the one that looks like a sports car because thats how peoples minds are trained to think sportty looking car = quicker.
Its kinda a mental placebo effect, hence why I asking if you had a boot up video seems like that would be proof enough.
Also ran a top command and suprise system is using 1% and its the top command so I dont see where you are coming up with the extreme cpu cycles you say journaling is causing. Not to mention the fact /system is pretty much only called upon boot. Most other times its going to be pulling r/w cycles from /data or /sdcard.
Click to expand...
Click to collapse
The placebo effect you are speaking of are typically people that don't know what they are doing, and are simply just excited about something.
An example of this would be the 9 out of every 10 posts I see in a ROM thread over the years talking about how much smoother their device is after flashing "xxxxx ROM"... a stop watch is a pretty reliable method for checking boot times, which is what I used for this particular scenario because I knew it would be relevant. Also the fact that my usage is pretty much exactly the same every day is a pretty solid test attribute. Any change in battery life at 15 hours... even if it is 1%... I notice it.
Also, my own personal ROM that I use is entirely odexed. So, nothing is being drawn from /data/dalvik-cache that is a /system/framework or /system/app function. It is noticeably more efficient because the 280+ .odex files are being read from the same location... which is now ext2, and not ext4.
Is this kind of starting to make sense now or am I losing you more?
I am not aware of all the file systems on linux. What happens to the partition if you restore a nandroid backup of the system partition that was converted to ext2 but the backup was ext4? And/or if backup was ext2? Just curious.
Sent from my SM-N900T using Tapatalk
Compusmurf said:
I am not aware of all the file systems on linux. What happens to the partition if you restore a nandroid backup of the system partition that was converted to ext2 but the backup was ext4? And/or if backup was ext2? Just curious.
Sent from my SM-N900T using Tapatalk
Click to expand...
Click to collapse
It will write the data to the disk as it should. You can do this without having any issues.
I've never tried restoring an EXT2 backup to an EXT4 formatted disk... So I have no answer for you there. It all kind of depends on exactly how TWRP's backups are created... I think they use .tars ... I'm not sure
Would this by any chance work on an AOSP/CM/AOKP ROM? I've tried using it with CM and LiquidSmooth but it stops every time after "erasing system" with "script aborted (no error message)".
Nevermind, I found out the issue. I went back into the updater-script and removed this line: "format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");". It flashed perfectly after that (Liquid Smooth AOSP ROM).
Edit: Had an issue with the ROM not booting at first, it hung on the splash screen. What I did was reboot into TWRP, wiped cache and dalvik cache, went into terminal (in advanced) and typed this command: "setenforce 0". After that, type "getenforce" and make sure SELinux is set to Permissive. I'm not sure if the SELinux command helped at all but I did it just in case.
Hypercore said:
Would this by any chance work on an AOSP/CM/AOKP ROM? I've tried using it with CM and LiquidSmooth but it stops every time after "erasing system" with "script aborted (no error message)".
Nevermind, I found out the issue. I went back into the updater-script and removed this line: "format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");". It flashed perfectly after that (Liquid Smooth AOSP ROM).
Edit: Had an issue with the ROM not booting at first, it hung on the splash screen. What I did was reboot into TWRP, wiped cache and dalvik cache, went into terminal (in advanced) and typed this command: "setenforce 0". After that, type "getenforce" and make sure SELinux is set to Permissive. I'm not sure if the SELinux command helped at all but I did it just in case.
Click to expand...
Click to collapse
Code:
"format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");"
Change that 4 to a 2...
Code:
"format("[COLOR="Red"]ext2[/COLOR]", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");"