This thread is for the discussion about the bounty and how to fix the poor IO performance
--> Bounty thread <--
A shellscript that do
-mount partition
-make a tarball of all data from this partion
-copy this tarball to /sdcard
-umount partion und format to new fs
-mount partion with new fs
-untar the tarball from /sdcard
for all relevant partion should be simple to write. After this the init.rc must modified to mount the new fs and not the old rfs. If the file is the same for all eclair firmwares, only this one has to change. The shellscript move the init.rc to init.rc.bak and copy the modified version.
This script can be started from an update.zip(I dont know if this possible). Or modify a recovery image, to start the script by a menu selection(this is possible).
I think this can be provide a simple solution for endusers. Unclear for me is why samsung use the rfs. This filesystem is optimized for flashdisks. It sounds like the internal nand has no wearleveling and a not flash optimized filesystem can damage the internal nand by rapid use to quickly.
I plan to test out how an external sdcard can provide the full os, not only partial like the speedhack. The init.rc file must modified to switch directly after start to the init.rc file on external sdcard. The init.rc from external sdcard start the the system from external sdcard. This variant reduce the modification on the phone and if the flashdisk is dead, the SGS is not a brick.
gr, Steffen from Germany
What types of file systems does the stock kernel support? Can it boot from ext2 as it can from this rfs?
Also: apparently the Nexus One uses the YAFFS2 file system for its root file system, which is made for use on NAND memory. Although it's probably easier to get kernel, tools and scripts to work for an ext2 based solution, we should probably look at getting a YAFFS2 fix eventually for best reliability.
I put up a quick guide over here which uses the playlogo hack. It's working perfectly for me and my phone is as smooth as butter!
http://forum.xda-developers.com/showpost.php?p=7571976&postcount=161
bub181 said:
I put up a quick guide over here which uses the playlogo hack. It's working perfectly for me and my phone is as smooth as butter!
http://forum.xda-developers.com/showpost.php?p=7571976&postcount=161
Click to expand...
Click to collapse
What firmware are you on?
As far as i remember, it is possible to ajust the times to which the filesystem (ext2,3,4?) syncs... If you increase that time, i would mean less writings to the nand - which again makes it last longer..
EDIT: spell correction.
andrewluecke said:
I'm concerned about this. People who are contributing to this bounty should consider:
1) Who decides if the fix is done? How exactly are you going to test? You can cause lag on every phone if you open enough crap, so how you going to test this? Or will you use a synthetic benchmark such as Quadrant?
2) Who verifies that the fix is safe. It's all good that you might end up with a solution where all lag is gone. But you might end up with a solution with no wear levelling which sucks up battery power because whenever the phone is idle it's performing online defragmentation.
3) Is battery life a consideration?
4) Remember, erasing flash memory also has a cost, which is why early SSD drives without trim slowed down a lot after a while, because they wouldn't erase it when the system was idle. So the fastest solution might be fast initially, but might write a lot of excess crap, which could affect long term results. Hence (1).
Before anyone explores a solution for this bounty, these questions must be answered, because disturbingly, I haven't heard 1 mention of SLC, Movinand or write cycle yet. I've only heard "RFS".
Furthermore, I've only heard "EXT", not "profiling tool" (has anyone actually profiled applications yet to isolate where the slowdown is). So, I think this bounty needs a bit more discussion.
It might also just be something simple, such as implementing something similar to Trim potentially (I myself aren't familiar with the architecture). Yes I want a solution too, but I want to ensure it's done properly.
Click to expand...
Click to collapse
We need to decide on how to test it!
My experience with lag
Hi Guys
The lag can be observed in two places:
1- While moving between windows in system apps (e.g. settings) or 3rd party apps (games, utilities). This lag keeps fluctuating, so sometime you would get it and sometimes you would not, and I DONT KNOW WHY
The above is definitely due to inefficient coding by Samsung
2- Second type of lag is when you try to start an App and you need to wait for a couple of seconds between the time you click on the App icon till the time you actually get a response (the App loads)
The above is inefficient coding by either Samsung or 3rd party App programmers. I DONT KNOW WHO
I believe that the first one could be solved, but there is no way in solving the second one as apparently the Android market does not enforce rules on 3rd pary programmers to make sure their apps are up to standard
On the other hand, i noticed that the second type of lagging was non-existant in Apple Store even for large applications/games because they enforce certain coding standards (as compared to Asphalt5 which is a big game and lags like hell when you want to load it)
Does what i am saying make sense, or is it that improving or patching the Samsung OS itself will solve all lagging problems for both the firmware and 3rd party Apps ????????????????
Apple has codingstandards that eliminates loading time? Thats impressive...
Sent from my GT-I9000 using XDA App
may I suggest contacting XDA user TKirton over on the Hero CDMA portal. He's written a fantastic implementation of Apps2sd which works across many platforms. He has great insight and knowledge of Android and linux filesystems and may be a good person to get on board with this.
Hi Guys
This thread is just to express gratitude to the guy behind post:
____________________________________________________
[UTIL] LagFix using update.zip's - v2.3.2
http://forum.xda-developers.com/showthread.php?t=765820
____________________________________________________
I come from an Iphone 3GS background and I bought my Galaxy S a month ago, and after trying the phone with the firmware that came with it (JF4), I almost threw the phone at the wall
I upgraded then to different firmwares that kept floating on the internet until i finally settled on the JG8. This latest firmware was good but there was always annoying lag and occasional freezes here and there and some applications always took time to load (2 to 5 seconds freeze after i click the icon)............
Through my experience and posts i read in this forum i humbly concluded the problem was two folds: RAM and file system
So i decided to tackle the problem using two approaches, a memory manager, and a file system fix
so i installed "Auto Killer" from the market and set it to "extreme", and installed the lag fix v2.3.2 posted by Tayutama
I constantly get around 150 Mb of free RAM and My SGS now is even better than the 3GS in terms of fluidity and responsiveness,and on top of that i have an open operating system as compared to the closed limited Apple IOS
I dont know what the coders at samsung mobile are doing, but they definitely have to take a look at what is happening at XDA forums
I almost sold the phone a couple of days ago, but now i would not sell it for double the price.
out of being realistic, i have to say that the only problems still at hand now are the following:
1- slight freeze when an app has fully downloaded from the market and is being installed. My old 3GS never froze during app installation. I really dont know how apple has managed to pull this up
2- If you're using the SGS as a business phone (which i am doing), then syncing with outlook is of great importance (calendar, contacts, notes, tasks) and still there is no application than enables you to do those on the SGS. Kies is a ****ty (pardon my french) piece of God forsaken software that needs a lot of improvement
Peace out
RADLOUNI said:
I dont know what the coders at samsung mobile are doing, but they definitely have to take a look at what is happening at XDA forums
Click to expand...
Click to collapse
I have no clue why ext4 wouldn't make sense to use. But let us for arguments sake say that it makes the phone unstable in some way (poor implementation in android or whatever the reason). That instability is likely rare, but if 1 out of 500 people experience dataloss because of it, it would be 10000 people experiencing dataloss on the phone (with 5 million phones sold). That's not acceptable, and compared to that, the lag is preferable.
Very nice and informative post. In regards to the data loss, one can agree on that. I think most people who come from iPhone to SGS know what they're getting into (XDA that is )
mickeko said:
I have no clue why ext4 wouldn't make sense to use. But let us for arguments sake say that it makes the phone unstable in some way (poor implementation in android or whatever the reason). That instability is likely rare, but if 1 out of 500 people experience dataloss because of it, it would be 10000 people experiencing dataloss on the phone (with 5 million phones sold). That's not acceptable, and compared to that, the lag is preferable.
Click to expand...
Click to collapse
Yeah right, android is still just stock linux at it's core. EXT4 is far more tested and robust than RFS. The reasons for choosing RFS cannot be technical, because RFS is technologically antiquated (it has all the performance 'features' of FAT32).
There is far more chance of data loss by using RFS than there is by using EXT4. Data loss in general is just plain unlikely on a super fast NAND device connected to a permanent battery like the internal SD card in our SGS. The main reason for things like 'safe' filesystems is because of slow physical magnetic write media (which used to be able to make mistakes when writing), which would stop spinning as soon as power stopped, leaving you with a long line of incorrect data.
Phones are just plain unlikely to ever have filesystem data corruption because of the very advanced NAND controllers on the storage devices. It is probably possible, but it is also possible for the battery in your phone to melt down, and burn your hand.
EDIT: Just to add, since we are talking about filesystems: the mythical magical iPhone (2G/3G at least) uses a non-journaled HFS+ filesystem for it's storage onto a NAND flash device - just the same as the SGS.
Non-journaled HFS+ is very very similar to EXT2. Nobody on an iphone has lost data because of their non-journaled filesystem (although you can't pull out an iphones battery). EXT4 is safer still than EXT2/HFS+. Just to put this in perspective when talking about mythical 'data safety'.
mickeko said:
I have no clue why ext4 wouldn't make sense to use. But let us for arguments sake say that it makes the phone unstable in some way (poor implementation in android or whatever the reason). That instability is likely rare, but if 1 out of 500 people experience dataloss because of it, it would be 10000 people experiencing dataloss on the phone (with 5 million phones sold). That's not acceptable, and compared to that, the lag is preferable.
Click to expand...
Click to collapse
How is it that other phone vendors managed to uphold both, data integrity and speed (you know which vendor i ak talking about)
Sent from my GT-I9000 using XDA App
THC? ouch I meant... ***
Damn those letters.
RADLOUNI said:
How is it that other phone vendors managed to uphold both, data integrity and speed (you know which vendor i ak talking about)
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
1. Non-removable battery. (You can get this same effect on your SGS by not removing the battery while the phone is on)
2. Very solid and fast (if a bit antique) HFS+ filesystem, that is similar to EXT2.
That is all it takes.
Can anyone tell me whats the real difference between the EXT2 and EXT4 based on the lagfix ?
EarlZ said:
Can anyone tell me whats the real difference between the EXT2 and EXT4 based on the lagfix ?
Click to expand...
Click to collapse
i like to know also.
EarlZ said:
Can anyone tell me whats the real difference between the EXT2 and EXT4 based on the lagfix ?
Click to expand...
Click to collapse
The currently lagfix makes a buffer between android and samsungs' RFS filesystem. EXT2 is a simple buffer that works very well and is fast. EXT4 is a more complex buffer that is believed to be more safe.
Possible differences:
Pulling out the battery while the phone is running may be safer in EXT4, as well as data safety in general may be better. No conclusive tests have been done (or possibly can be done) to determine this, though.
Real differences:
EXT4 is slower than EXT2.
Real solution:
Remove RFS entirely. Hopefully soon.
RADLOUNI said:
2- If you're using the SGS as a business phone (which i am doing), then syncing with outlook is of great importance (calendar, contacts, notes, tasks) and still there is no application than enables you to do those on the SGS. Kies is a ****ty (pardon my french) piece of God forsaken software that needs a lot of improvement
Peace out
Click to expand...
Click to collapse
I don't know what you are talking about here, Android has over the air exchange sync of contacts, mail, and calander built in.
brunes said:
I don't know what you are talking about here, Android has over the air exchange sync of contacts, mail, and calander built in.
Click to expand...
Click to collapse
Exactly what I was about to mention, and if you really wanna use outlook together with google calendar on phone and web, then simply install google outlook sync http://www.google.com/support/calendar/bin/answer.py?hl=en&answer=89955 and have them work together with w/e mailsystem youre using.
mickeko said:
I have no clue why ext4 wouldn't make sense to use. But let us for arguments sake say that it makes the phone unstable in some way (poor implementation in android or whatever the reason). That instability is likely rare, but if 1 out of 500 people experience dataloss because of it, it would be 10000 people experiencing dataloss on the phone (with 5 million phones sold). That's not acceptable, and compared to that, the lag is preferable.
Click to expand...
Click to collapse
For starters, it might be because nobody actually knows if running EXT4 exclusively performs proper wear leveling with this phone (because nobody has actually checked where wear leveling is performed). Filesystems which do perform wear levelling and such do tend to be a lot slower than ones that don't. Is it possible that the lagfixes are flushing the data much less often too? Because, then it's additional speed, at the greater risk of losing data..
andrewluecke said:
For starters, it might be because nobody actually knows if running EXT4 exclusively performs proper wear leveling with this phone (because nobody has actually checked where wear leveling is performed). Filesystems which do perform wear levelling and such do tend to be a lot slower than ones that don't. Is it possible that the lagfixes are flushing the data much less often too? Because, then it's additional speed, at the greater risk of losing data..
Click to expand...
Click to collapse
I believe someone checked the internal SD, and it was regular flash as in normal SD cards. I have also read that large flash devices require the type of controller that does wear leveling to even function at all. So while it is not certain, and RFS is closed source, it seems very likely that there is hardware wear leveling. I don't believe it is actually possible to aquire flash memory of this size without it. Plus, every single piece of hardware in this device is top of the range. The internal SD card itself appears to be a very high quality class 10.
At any rate, for EXT on RFS, the under-the-hood operations are identical to creating a very large 1GB file on RFS and then doing lots of small writes inside that file. Perfectly normal operation for a filesystem, so if RFS is doing the wear leveling, then it will still be doing wear leveling.
Your last point is completely accurate, and is the entire point of the lag fix!
Because RFS writes are slow and block the system, we use EXT2 to buffer these writes, so that they get written in a big chunk! This means you can lose the unwritten data if you pull the battery out while the phone is running.
You have a chance of losing data on any filesystem if you just pull out the battery while it is writing anyway! (Email comes in, is half written to disk, and you pull the battery! Now you have half an email on disk, no matter the filesystem! Batteries should be left inside the device until you turn it off.. should be obvious! )
tndb said:
Exactly what I was about to mention, and if you really wanna use outlook together with google calendar on phone and web, then simply install google outlook sync http://www.google.com/support/calendar/bin/answer.py?hl=en&answer=89955 and have them work together with w/e mailsystem youre using.
Click to expand...
Click to collapse
This application syncs only calendar, or all the other stuff like contacts, tasks, notes.............
Edit
just tested the application and it syncs only calendar, not what i am looking for
How !!!!
brunes said:
I don't know what you are talking about here, Android has over the air exchange sync of contacts, mail, and calander built in.
Click to expand...
Click to collapse
so android can sync contacts, mail, and calender without any third party app, please tell me how ??
What are the possibilities of using our 2gb of ddr program storage and re allocating it as system ram?
Even if it isn't pure flash (slow speed) I imagine it would be better then nothing, we could always store programs on the sdcard.
Sent from my GT-I9000 using XDA App
android53 said:
What are the possibilities of using our 2gb of ddr program storage and re allocating it as system ram?
Click to expand...
Click to collapse
very good, this post actually explains how to make a swap file (on /cache which is fast nand!).
if you want a swap partition you could a) use part of the 2gb /data partition for a new swap partition which you create in a project-voodoo like manner -> not very easy to do as you would have to repartition /data before boot OR b) just make a 2nd partition on your external sd card to swap on. a lot of people (me included) actually did this with their htc magic.
but to be honest i don't think that you will gain any speed improvements with this, on the contrary your system will be slower an more laggy... i found swap even worse on the magic with ~90mb of user-available-ram. if you want to try it nevertheless, it think the swap file on /cache would be a good start!
jodue said:
very good, this post actually explains how to make a swap file (on /cache which is fast nand!).
if you want a swap partition you could a) use part of the 2gb /data partition for a new swap partition which you create in a project-voodoo like manner -> not very easy to do as you would have to repartition /data before boot OR b) just make a 2nd partition on your external sd card to swap on. a lot of people (me included) actually did this with their htc magic.
but to be honest i don't think that you will gain any speed improvements with this, on the contrary your system will be slower an more laggy... i found swap even worse on the magic with ~90mb of user-available-ram. if you want to try it nevertheless, it think the swap file on /cache would be a good start!
Click to expand...
Click to collapse
If we go for b, will the sgs detect and use the swap partition or do we need to do something else.. I still use my htc magic along side my sgs
Sent from my GT-I9000 using XDA App
i have tried using a swap file, but i didnt c any improvements, and the usage was about 500kb only
I recall that on liquid we managed to use a ramzswap module, which fakes a zipped swap partition in ram. It causes cpu to work a bit more, but it was still efficient.
Elvoski said:
If we go for b, will the sgs detect and use the swap partition or do we need to do something else.. I still use my htc magic along side my sgs
Click to expand...
Click to collapse
you would have to repartition our external sd to have a second (linux swap) partition.
then use mkswap to set the partition up and after that call swapon. swapon has to be redone every time you restart but you could place it in a playlogos1 script to automate that.
captive said:
I recall that on liquid we managed to use a ramzswap module, which fakes a zipped swap partition in ram. It causes cpu to work a bit more, but it was still efficient.
Click to expand...
Click to collapse
compcache?! ... i guess this would also be a good trade off for our galaxy s because the cpu is definitely not the bottleneck here...
btw. a good read about swap & compcache from the cyanogenmod wiki: swap & compcache
android53 said:
What are the possibilities of using our 2gb of ddr program storage and re allocating it as system ram?
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Bad, bery bad idea, MoviNand is not in any way releated to DDR. It's waaaay slower.
Also, RAM is designed for virtually unlimited data read/write counts.
NAND memory is not.
What would be the benefit of using swap space? Nothing. Data is being read/written in filesystem in the end. No improvement in performance. (It could be seriously degraded).
This behavior is totally against Android core design principles. Android doesnt use swap because it doesnt need to. Programs not fitting into "RAM" are being closed with their state remembered. When program is re-launched it is loaded from filesystem and its state is being restored.
If we had "swap" space, it would become really messy. Just imagine:
System wants to close program X, resident in swap, it needs to:
- restore program from swap to RAM (talk about additional ram needed)
- close program, resulting writing state to FS.
i was talking about this sort of thing with Ryza and Voodoo guy they said it was too much work
i'm forward with the idea of using a Swap drive in RAM or external SD
to prevent over usage on the internal SD
This means external SD would need to be powered up at all times -> battery drain (it is present with APPS2SD - or whatever this name was)
Wuld this mean that we would have extra ram available for running apps...like SGS task manager will show more than 311Mb RAM ?
If this is the case then I am very interestied, since I don't care about speed so much. I just need to run an app that currently can not run due to out-off-memmory (needs 130Mb of RAM) for pure presentation purposes
There is a app in market called swapper2 which can make use of the swap partition or creates a swap file for use. I had been using this app since my HTC MAGIC and now on SGS.
I'm currently using swap partition that had been created earlier in my class 6 SDCard. Works on both eclair or froyo kernels on SGS. So far I am not complaining, with swappiness 20, there is not much of memory hog or lag due to opening too many apps or single memory hogging apps (like flash on browser) on my XXJPK, the swap memory gets allocated and deallocated as you can tell from the swapper info feature.
But the battery effects is something to think about though, sdcards are cheap so I don't mind sacrificing it. The other way is to create a swap file on the rfs and use it if you value your sdcard. The screenshot provided is a normal usage of my device with a few apps running at background (Still gonna be 300+ RAM, nothing magical about it though) and I had also used minfree tweak on the kernel.
You can try and see if it helps in terms of performance for a few days. I cant vouch for the swapper a lot as I'm using it myself - I am more uncomfortable without it though. What Xan said does makes sense but there are rare times when the things that doesn't makes sense gives us surprises.
A good read up and comments from people who had tried and used it in different scenarios...
http://zerocredibility.wordpress.com/2009/08/24/why-android-swap-doesnt-make-sense/
Sent from my GT-I9000 using Tapatalk
MOD IS FOR ANDROID 4.1.2 FOR T-MOBILE NOTE 2 ONLY. DO NOT USE WITH CM. CHANGE LOG AT THE END OF THIS POST
SYSTEM DATA AND CACHE ARE NOW WORKING 100%. ALSO, PLEASE SEE POST #72 FOR FURTHER INSTRUCTION ON SETTING UP YOUR CPU PROFILES APPROPRIATELY TO INCREASE STABILITY AND PERFORMANCE
BIG bug fix in aroma... we have figured out what is causing boot loops. The issue is that twrp is mounting data as ext4 after the mount command is executed. This is an issue with twrp, not aroma. Instructions at the end of this post on how to get around this until we figure out how to cause this not to happen...
As of right now these modifications are only being provided to you for touch wiz. I will not provide links to CM based kernels simply because is more prone to being unstable. Do this mod on CM on your own, and at your own risk. Again, kernels in this thread are touchwiz based, and will not work on CM ROMs.
First of all, let's talk about file systems.
ext2 - (second extended file system in linux) is different from ext3 and ext4 in the sense that it does not use something called journaling. There are other differences as well, but for the sake of showing what kind of performance improvements this file system provides over the latter two (3 and 4), we'll cover what is relevant to us Android users. Data is directly written to a disk as it comes through on ext2 devices.
ext2 does have file limitations compared to ext4. ext4 uses pre allocation of blocks and delayed allocation of data writes and also organizes data a little more efficiently on inodes/blocks. It also has a way to "mark" unused blocks, this reduces IO search times. ext4 also uses a checksum in the journal to improve reliability since the journal is one of the most used files of the disk. In a nut shell, journaling is an overhead feature of ext4 that ensures file/data integrity. This is useful if a system is not shut down cleanly, or the stability of the system has been compromised in some way. And even THAT being said, ext4 has it's own unique issues with data corruption through the delayed allocation feature. Furthermore, and probably the most important to note, those features are really only useful when you have extremely large disk sizes in the exabyte or terabyte range. Our devices are INCREDIBLY small in disk size. ext4 really only outshines ext2 in performance when you are dealing with large databases (and 16 GB, partitioned, is not large... at all). The point to bring up here is that ext4 is only used on these devices out of the factory for total stability. The devices were not designed out of the factory with the advanced user in mind, they were designed with the everyday person soccer mom who needs a "safe" device that will take and handle all kinds of beatings and abuse. The cost for that, unfortunately, is performance. So let's fix that problem.
Here is some more info about it online, an extremely informative article of some test data samples of different files systems in Linux, and their performance.
http://mindplusplus.wordpress.com/2012/01/11/finding-the-fastest-filesystem-2012-edition/
This thread is going to show you guys how to convert your file systems to ext2.
First of all, let's address some useless init.d scripts that I have seen littered all over ROMs to "optimize" ext4.
Code:
tune2sfs -o journal_data_writeback /dev/block/mmcblk0p13
tune2fs -O ^has_journal /dev/block/mmcblk0p13
mount -o remount,noatime,noauto_da_alloc,nodiratime,barrier =0,nobh /system
and so on and so forth for the other two partitions (cache and data)
Now, to be fair, the implementation of this code is not utterly USELESS per say. It does provide a very small amount of IO performance increase. However, this fact still remains:
The op paths in the fstree are optimized for the journal, so simply disabling it makes the code path redundant. And furthermore, the journal-optimized block sizes now have empty overhead (basically you are still using the exact same amount of disk space). On top of that, the performance increase really is not noticeable. Therefore, it is not worth the trouble. And most of the time these "hacks" are tossed into /etc/init.d/ and the user comes alone not knowing to make a back up after flashing this ROM, or has no clue what these actually do (and sometimes the dev doesn't quite understand it either).
ext2's strength is it's simplicity, which goes well with "noop" IO scheduling if the fs itself relies on virtually NO ops. As it comes through, so it is done. The performance benefits of this are absolutely unreal you guys. Your device that used to boot in, say, 30 seconds? - Now boots in maybe 10. That is the real time performance difference we are talking about here. Cut out all the hoopla of ext4.
For those of you who are saying "well what about stability??" my answer is simply this: if you refuse to make a back up of your data and system (recoveries are called recoveries for a reason) you are simply doing yourself a disservice. I have been using ext2 file systems for a long time now, and let me tell you - never will that change. You just can't beat the performance, and the reliability is as sound as you make it - if you are one of those that feels the need to run your processor on performance all day at 2.4 GHz, well you are bringing about your own problems. BUT, like I said, even for the extremist, JUST MAKE A BACK UP OF YOUR DATA!!!! - gravy. :good:
DIRECTIONS>>>>
1.Download and flash your ROM of choice. Or if you have one installed that you like, just boot to recovery and proceed.
2.In TWRP, make a backup of your /system and /data, do not enable compression, just do it how I did it and save yourself some potential headache. If your backup gets ****ed. It’s time to reflash from scratch.
3. Since you will be wiping data, your backup cannot stay on your internal SD. So boot back up, and copy that SOB to your desktop computer. It should be in your internal storage under a directory named “TWRP”. Open it up and COPY, do not cut, the “BACKUPS” folder to your computer and/or external SD card… also, verify both of your backups are actually in that folder before you proceed. There will be one for system and data, and a couple of md5 files, some logs, etc etc… a handful of files. Also, download the two kernels attached in this thread … “TNT-ext2_sys_TMO-TW23-600” and “TNT-ext2_sys_cache_data_TMO-TW23-600” and put them on your EXTERNAL SD CARD. INTERNAL SD IS NOT AN OPTION BECAUSE IT WILL EVENTUALLY GET WIPED IN THIS PROCESS.
4. Boot back to recovery, go to settings, and change the format option to “format using rm –f” ALWAYS ALWAYS ALWAYS FROM THIS POINT ON MAKE SURE THAT IS CHECKED EVERY TIME YOU GO TO RECOVERY
5.After you do that, go back to TWRP main screen, select “advanced” and “terminal” or whatever… it will ask you for a starting directory. Just make sure you are at root, then hit the little button on the bottom that says “select”… it will then take you to a terminal session.
6.From terminal, type the following command then hit enter or “GO”
Code:
“mke2fs /dev/block/mmcblk0p13” (without quotes)
MAKE SURE YOU TYPE THAT CORRECTLY! CANNOT STRESS THAT ENOUGH 0p13 0p13 0p13 0p13 0p13 0p13 0p13 0p13 0p13 ZERO P THIRTEEN SAY IT IN YOUR HEAD
Let it finish. It will only take a couple seconds.
7.After it is done, hit the back button until you are on the main screen on TWRP again… and just for good measure, again verify in your settings that “format with rm –f” is checked. Now go back and select “restore” from main MENU in TWRP. Restore your system backup only.
8. After that is done, flash the “TNT-ext2_sys_TMO-TW23-600” kernel.. again, make sure this is not the sys_cache_data version. Your other two partitions are not formatted yet.
9. REBOOT! Enjoy your system on ext2 and battery and performance improvements. If you only want /system as ext2, stop here. If you are the extremist, and want data and cache optimized as well, proceed.
10. Since your internal storage such as downloads, zedge files, whatever else you have on there, is going to get wipe during THIS phase…. Please make backups accordingly. Your entire internal storage is going to be reformatted – Again, prepare accordingly by backing it up to your external SD card or a desktop computer.
11. Boot back to recovery, at this point your system is already ext2, cache and data are still ext4. So here we go. And I will take you through the long process but the safest.
12. From Recovery MAIN menu, select “MOUNT” and uncheck the boxes for cache and data. Go back to main menu.
13. From recovery MAIN menu, select advanced again, (PLEASE FOR THE LOVE OF HADES AGAIN MAKE SURE YOU HAVE BACKUPS OF YOUR STUFF… if you come crying in here about “hey my downloads and zedge ringtones were wiped wtf bro” I will ignore you and wish death and damnation upon you, you noob. So just don’t do that. Make backups before proceeding)… ok, so again after hitting advanced, select the terminal again, make sure you are at the root directory, hit that little select button. You are now in another terminal session.
14. From terminal, type the following commands (WITHOUT QUOTES and hit enter after each one)… and please again for the love of EVERYTHING HOLY TYPE THIS CORRECTLY AND DOUBLE CHECK CORRECT NUMBERS ARE PUNCH IN AFTER “p” … have this page open while doing this. Look at it, and then look at it again. This is pretty straight forward stuff guys, but a small mistake can be detrimental. So please pay attention.
Code:
“mke2fs /dev/block/mmcblk0p12” <--this is the cache partition
“mke2fs /dev/block/mmcblk0p16” <--this is your data partition, including internal SD.
Now we need to manually create your /data/media/ directory… because it is gone right now buhbye. Rofl
Again, straight forward… without quotes… you get the idea by now
Code:
“mkdir /data/media”
BOOM.
15. Go back to TWRP MAIN menu, and flash “TNT-ext2_sys_cache_data_TMO-TW23-600”
16. Reboot.
17. Success! You are now on ext2 file systems for /system, /data, and /cache.
At this point you have 2 options. After your device reboots, you will be asked to sign back into your google accounts, etc etc etc… data was wiped, so you are at square 1 again with your particular setup. If you wanna set up real quick (like say you are the simple type that just has a few apps, not a whole lot of work to get back to where you were, etc) then maybe a restore isn’t really necessary. You decide. If you neeeed your bajillion million apps restored, no problem. Continue reading.
18. Hook your device up to your PC, find your internal storage. There should be a directory there named “TWRP” if it isn’t there, simply create it.
19. Grab that “BACKUPS” folder and drop it in the TWRP directory of your internal SD.
20. Reboot to recovery.
21. GO TO SETTINGS AND VERIFY “format with rm –f” is still checked… otherwise you are starting this whole instruction over again. Lmaooo… happened to me last night. I’z like…..fakk.
22. All good? Ok now go back to MAIN menu, select restore, and restore both system and data
23. After that is done, MAIN menu… just for good measure…. Select WIPE, then ADVANCED WIPE… and wipe ONLY CACHE once… two… times…. 9 times… whatever tickles your pickle people I’m OCD so even though I know doing it more than once is redundant and unnecessary I do it twice.
24. REBOOOOOOOOOOOOTTTTTTTT
Well wasn’t that fun? Now always keep a backup of your system and data handy (just in case you ever need it, or you have a lockup, whatever the case may be where you feel like your system has been compromised) and you will be a-ok. I’ve personally never had issues with this.
Enjoy.
Download links for modified kernels are up! See below... Thank you morfic for allowing me to post copies of your kernels here. Only things changed are mount points to accommodate the new ext2 paritions. His git is here>> https://bitbucket.org/morfic/note2-tw
UPDATED WITH fsck DISK CHECK FOR INIT.D.... remove the ".txt" extension and drop this file into /etc/init.d and give it full permissions.
Instructions for flashing with aroma installer***********
1. Put aroma installer on external SD card
2. Boot to recovery (make sure you have already flashed the ROM you want to use)
3. Once you are in recovery, make a back up of your current system using the twrp method and CHANGE THE BACKUP LOCATION TO YOUR EXTERNAL SD CARD. Then going into settings, and check the box that says "format using rm -f" or whatever it says... you'll see it once you are there. MAKE SURE THIS IS CHECKED! EVERY TIME you go to do this. The only time you should uncheck this option is if you are trying to revert back to ext4.
***Cannot stress #3 enough you guys, it was the reason you were all boot looping. If you come back here saying you are boot looping, I will e-slap you so hard your face will actually hurt. We will raise up armies against you and those around you. Carnage will ensue. Ok maybe not.... but just make sure every time you go into recovery to do something with this aroma installer that you check that box. EVERY TIME... because sometimes it unchecks itself.
4. Well, easy enough. Now flash the installer. Only use it to convert /system for now, and use the manual method (above) for /data
You can try doing data through the aroma installer, just make sure you check that box in settings of twrp before you attempt to do so.
"That was easy."
AROMA INSTALLER FOR EXT2
http://tweaked.mediafire.com/download/ody7u8wxzarjv37/ext2inizer.zip
md5 = EB0EB296B06DF5BEFFAA26D1D39291DA
Seem appropriate to start a change log for this.
July 19, 2013
Stock kernel added as an option in aroma for those who cannot run morfic
No more options in aroma to only do /system. You now can only do all 3.
July 18, 2013
K this should be nailed down now.
July 17, 2013
1. Bug found. Boot looping issue has been identified and pinpointed. See flashing instructions. (above)
July 16, 2013
1. Misc code fixes in aroma (more like optimizations really) for the backup logic
2. fsck script for init.d updated - calls to /system/xbin now
3. Some more manly stuff
Previous Versions
1. Initial release and various small optimizations with aroma
Great write-up. Interesting info
Sent from my SGH-T889 using xda app-developers app
So much reading
Sent from my SGH-T889 using xda premium
Just a quick update on this… I want to give you guys an idea of just how much overhead is generated by your ext4 file system.
Right now I am currently sitting at 87% battery, 5 hours off the charger, and 1 hour and 3 minutes screen on time.
This is only with /system mounted as ext2. /data and /cache are still mounted as ext4.
To give you a comparison (and my usage throughout the day is 100% consistent, so I am a good test model for this particular thing) 5 hours off the charger, at 82%.... I am usually looking at about 50 minutes of screen on time.
In short, simply changing my /system partition to ext2 has saved me 5% battery at this point in my daily activities, while still gaining 12 minutes of screen on time.
So converting that….
Improved screen on time by 25%, and overall system usage and battery drain has improved by about 60%
That is just /system
EDIT** screen of /cache successfully mounted as ext2
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Hi I am looking for a long time to convert my SD card and my system to Ex format because I cannot use my 32 gb sd card efficient for example my limit is 5gb would that fix my problem?
Since you like to convert between filesystems, do us all a favor and run Bonnie++ on them.
http://forum.xda-developers.com/showthread.php?t=1169910
Maybe there is a noticeable difference on Note2 hardware, but in the past, it hasn't been the case. To keep things "even", run from adb shell in recovery. That way you don't have the pesky OS overhead etc... Just format a partition, run the test, copy/paste the results, format and run again.
Now, that IS a benchmark and all the usual benchmark caveats apply, however, it is also a useful start to determine how the hardware handles the various cases.
Speaking from experience on previous phones, particularly the Samsung Vibrant, the speed difference wasn't really noticeable. You could see it in benchmarks, but in real life, if I were to write a boot script that would randomly change them back and forth, 99% of users would never notice. Now, the downside of ext2 did rear it's ugly head a few times, with users getting stalled boots and having to run fsck at boot after a crash, or power loss. Complete filesystem loss is possible in theory, but I've never seen it, so let's just discount that one. Early mods didn't account for needing to run fsck and would stall the boot, to the user it looked bricked. If you do end up needing fsck, it can make those "long" ext4 boot times look pretty fast..... However, none of the failure scenarios are really all that likely, so let's stick to performance.
As I said, Note2 hardware is different. Just putting the past out there. This is OLD ground. Perhaps the hardware makes all the difference..... From some of the previous testing back in the day, JFS and Reiser looked like good candidates for phones.... I don't know if anyone ever actually tested running Android on them though.
patches said:
Since you like to convert between filesystems, do us all a favor and run Bonnie++ on them.
http://forum.xda-developers.com/showthread.php?t=1169910
Maybe there is a noticeable difference on Note2 hardware, but in the past, it hasn't been the case. To keep things "even", run from adb shell in recovery. That way you don't have the pesky OS overhead etc... Just format a partition, run the test, copy/paste the results, format and run again.
Now, that IS a benchmark and all the usual benchmark caveats apply, however, it is also a useful start to determine how the hardware handles the various cases.
Speaking from experience on previous phones, particularly the Samsung Vibrant, the speed difference wasn't really noticeable. You could see it in benchmarks, but in real life, if I were to write a boot script that would randomly change them back and forth, 99% of users would never notice. Now, the downside of ext2 did rear it's ugly head a few times, with users getting stalled boots and having to run fsck at boot after a crash, or power loss. Complete filesystem loss is possible in theory, but I've never seen it, so let's just discount that one. Early mods didn't account for needing to run fsck and would stall the boot, to the user it looked bricked. If you do end up needing fsck, it can make those "long" ext4 boot times look pretty fast..... However, none of the failure scenarios are really all that likely, so let's stick to performance.
As I said, Note2 hardware is different. Just putting the past out there. This is OLD ground. Perhaps the hardware makes all the difference..... From some of the previous testing back in the day, JFS and Reiser looked like good candidates for phones.... I don't know if anyone ever actually tested running Android on them though.
Click to expand...
Click to collapse
Well, I wouldn’t really call this benchmark irrelevant… but it is certainly not needed because the logic and theory behind the two file systems is sound and proven.
Of course you are not going to SEE a difference when opening, say, your messaging app even tho it is mounted to an ext4 system. But the performance benefits are still there, the reduced IO operations on your disk are real (that is reflected in battery life, as I mentioned above), and your boot times being faster is also a real time that you can see. Less cpu cycles, less overhead, more efficient. The operation is still taking place, is what I am saying. And having a powerhouse processor like these that uses more juice to complete a task than the devices of old (two years ago, rofl) is all the more reason to optimize as much as possible.
As far as the “instability”, like you, I have not personally experienced any of the horror stories of data corruption or a total system loss at a catastrophic level, nor have I ever had problems simply booting the device.
All I can say is this fact remains: ext2 > ext4 when it comes to performance. My whole idea behind this stems from the fact that as root users of these machines, we have the luxury of backups, and therefore we have no reason to not run a truly optimized (performance-wise) file system. Ext4 is a waste of disk space and cpu cycles on these devices.
Just my opinion of course. I’ll run the benchmark, however, just because I am curious to see what it says.
b rrrrr bbbb
This is work is for all kernels?
Sent from my SGH-T889 using xda premium
jpeps said:
This is work is for all kernels?
Sent from my SGH-T889 using xda premium
Click to expand...
Click to collapse
This will work for all kernels that support ext2 (most should)
It will still require you to change the mount points, however. That I cannot do for you.
Updated.... Successfully mounted ext2 file system for /data/
Holy monkey balls r/w speeds are nuts. Device booted in about 15 seconds.
I'll have a battery stat report tomorrow...
Please make video how to do this or how to
Thanks
Sent from my SGH-T889 using xda premium
Admiral Sir Manley Power said:
Well, I wouldn’t really call this benchmark irrelevant… but it is certainly not needed because the logic and theory behind the two file systems is sound and proven.
Of course you are not going to SEE a difference when opening, say, your messaging app even tho it is mounted to an ext4 system. But the performance benefits are still there, the reduced IO operations on your disk are real (that is reflected in battery life, as I mentioned above), and your boot times being faster is also a real time that you can see. Less cpu cycles, less overhead, more efficient. The operation is still taking place, is what I am saying. And having a powerhouse processor like these that uses more juice to complete a task than the devices of old (two years ago, rofl) is all the more reason to optimize as much as possible.
As far as the “instability”, like you, I have not personally experienced any of the horror stories of data corruption or a total system loss at a catastrophic level, nor have I ever had problems simply booting the device.
All I can say is this fact remains: ext2 > ext4 when it comes to performance. My whole idea behind this stems from the fact that as root users of these machines, we have the luxury of backups, and therefore we have no reason to not run a truly optimized (performance-wise) file system. Ext4 is a waste of disk space and cpu cycles on these devices.
Just my opinion of course. I’ll run the benchmark, however, just because I am curious to see what it says.
b rrrrr bbbb
Click to expand...
Click to collapse
Fewer instructions doesn't necessarily == greater performance. There was a lot of time between ext2 and ext4, a lot of work was done on the underlying code in that time. In many tests, ext4 reads out-perform ext2. As the storage is by far the slowest part of any computer, using a few CPU cycles for better caching etc. is often well worth the tradeoff. Performance of the two is by no means a given, this was hotly debated long ago and the same issues remain. I'm an open minded sort of person, so I'm not saying it isn't possible that it makes a bigger difference now.
One note... while current CPUs use more power at the higher clock speeds, they also complete the tasks faster, and thus, spend less time at higher clock speeds, getting back to sleep faster than older CPUs. Modern chips also have features that older chips did not, like sleeping individual cores. There are a LOT of variables at play, it's never as simple as that.
ttabbal said:
Fewer instructions doesn't necessarily == greater performance. There was a lot of time between ext2 and ext4, a lot of work was done on the underlying code in that time. In many tests, ext4 reads out-perform ext2. As the storage is by far the slowest part of any computer, using a few CPU cycles for better caching etc. is often well worth the tradeoff. Performance of the two is by no means a given, this was hotly debated long ago and the same issues remain. I'm an open minded sort of person, so I'm not saying it isn't possible that it makes a bigger difference now.
One note... while current CPUs use more power at the higher clock speeds, they also complete the tasks faster, and thus, spend less time at higher clock speeds, getting back to sleep faster than older CPUs. Modern chips also have features that older chips did not, like sleeping individual cores. There are a LOT of variables at play, it's never as simple as that.
Click to expand...
Click to collapse
While I agree with some of what you said, the fact of the matter is ext2 out performs ext4. Mostly because even though ext4 has all of these nifty little pre-allocation for blocks, and inode/block numbering, and even a function in place to mark blocks that are not being used so it knows where exactly to search when a request is made on the disk (this is where that read performance comes in that you speak of)... it is still slower because of journaling. And you still have overhead IO operations. And disabling journaling doesn't fix that entirely, it just makes it more unstable.
HOWEVER... you are still wrong, and whoever debated that ext4 outperforms ext2 on these devices, was also wrong. Let's break this down a bit. So you can understand where my logic is coming from to make that conclusion.
First of all, I will say this, and it is fact. The ONLY reason google switched to ext4 was because they needed a file system that could handle MUCH MUCH larger disks. ext4 has far greater file capacities, and also overall disk capacity than ext2. We are talking exabytes, terabytes, not measily 16 GB devices such as these.
A full odexed ROM on this device, for example, has a total of about 1900 system files, it is less if you are de-odexed (dex files are moved to /data/dalvik-cache). ext2 has an overall file subsystem limit of 32,000, I believe (off memory please correct if I am wrong) and ext4 has some number ridiculously higher than that... I think it is actually 64,000 if I'm not mistaken. Why is this relevant? Because the ONLY reason ext4 has ALLLLLL those cool little extra overkill organizing features is because it is designed to handle data and file clusters that are literally 100 times larger (or even more) than a measily little Android OS that takes up 1.2 GB of space on a 1.7 GB partition ... ext4 is overkill for these devices and the only reason it is implemented by Samsung and Google is because they want it to be as reliable as possible. The average user will not know how to make a backup, root, or restore a backup if something goes wrong.
ext2 is simple and fast. The fact that it was developed years ago doesn't mean anything. "Improvements" in these types of things are most of the time brought about by some type of demand, not necessarily because it is faster or more efficient. In ext4's case, the demand was larger storage devices and a rock solid stable file system.
If you need another reminder of proof.... again read my reports of boot times and battery life. That should be enough evidence to undo whatever you may have read in the past about what is best for either.
Apply applications and modifications as necessary. I'm not running warehouse full of servers... it's a handheld computer with a very small operating system and disk. ext2 will outshine ext4 in any application like this.
Were I running servers, though, or were I Google.... yeah.... I'd probably be looking at ext4.
Just because the device was delivered to you with this or that, doesn't mean it is the best or fastest in that condition. Variables, again, were developers taking into account the every day user. Thus, they decided on ext4. You and I, are not the every day user.
I think it's time I leave this thread, you seem to be getting worked up over my little posts. I'll try once more though...
Search my history, I've done a LOT of work on various filesystem based things. Remember my mentioning the Vibrant? I contributed to Project Voodoo and did other related mods back then. ext2/ext3/ext4 with various options, installer based stuff, etc... And, from experience, on that particular phone, the day-to-day difference was very small. As I said, the Note2 is a very different beast, but the various filesystems haven't changed that much. I'll probably test your mod when there's an installer, I don't have time to fiddle with formatting everything myself these days.
As for battery life, I was leaving it alone as I considered it off topic.... The Android battery meter simply isn't accurate enough for the comparisons you are talking about here. It's an educated guess based solely on the voltage at the moment. Connect a logging ammeter inline and you might have something to go on. But the % meter is a red herring for any other comparison.
Boot time, well, I did say I thought it could be faster. The question is one of degrees. Frankly, the boot time isn't really that interesting... I don't boot my device that much.
What I care about is performance in general use and, to some degree, just pure faster I/O. As I mentioned, it's the slowest part of any system, making it faster is always nice. The system loads during boot are kind of a special case... What I care more about are things like how fast I can push records in/out of a sqlite DB from my app, copy files about, etc.. I suspect it will be faster on ext2, particularly for writes, the question is how much? Is it enough that I would notice on a daily basis? And yes, it depends greatly on the user, what apps they have installed, running in the background, various system options that would use memory, state of the cache, etc... But if it is a significant boost for the general case, it should be noticeable to the user.
There is also the error case... if you are writing to the FS and pull the battery.... what happens? ext2 gets angry when you boot. ext4 replays the journal, you might lose data, but you don't have FS issues and it doesn't refuse to mount until you run fsck on it. Now, it's possible ext2 has improved some since then, but do you have a boot check to ensure it's not an issue? You should if you want a general use setup. I'd rather have the device stall a bit while booting and run an automated fsck than just refuse to boot. As I said, this situation isn't common, but it was one we ran into back in the day, so I'm mentioning it for the sake of any users that follow your steps or use any flashables you set up. Please do include an init.d script to handle it. You can find some in the various mods from back then. I don't think people were losing data, but really, it's simple to just check for it and fsck at boot time. The fsck issue and the fact that the performance difference wasn't huge, led most to just use ext4 as it was faster than ext3 and didn't require boot checks. But, as they say, that was then. The situation could have changed. I'm curious to see what comes of this. Don't take me the wrong way, I'm trying to provide info so you don't end up getting caught on stuff I've seen before. And in typical user fashion, if this happens, you will have people coming here yelling that you bricked their phone, blah, blah, blah.
And now you see why I don't do much dev stuff on here these days. Good luck though.
Lol... Bro I'm opinionated and although I disagree with much of your statements, particularly about battery life and so forth (which isn't a percentage based on a bunch of different variables, it is actually quite simple and pretty accurate - x volts = x % ... Not hard to compute... Its also pretty straight forward logic, and monitored by the kernel, relayed through the OS... easy), don't take it as anything personal. I enjoy the back and forth technical conversation.
If you are running a note II, though, you should give this a shot. Really and truly I believe you'll have a positive experience with it.
I'll make a script later for init.d so we can reduce issues even more. I used to run ext2 "back in the day" as well and personally had no issues with it whatsoever. The key is to run a stable kernel, though, to be honest. There is no reason to not be able to run your device cleanly for weeks on end without a lockup or reboot. That is key, stable kernels.
Give it a shot, and see for yourself.
And stick around here... And share your insight. Seriously
Any luck on the kernels i cant find the download for them?
HOGWILD said:
Any luck on the kernels i cant find the download for them?
Click to expand...
Click to collapse
Yes waiting to hear back from a dev about posting his work here. He is a friend of mine, but he is also busy.
Updated OP with an fsck script for init.d... this is going to slow your boot times a bit, but very much worth it. Thanks tabbal for the suggestion (a good one indeed).
Still waiting to hear back from morfic about his kernel... I dont think he will have a problem with it but I respect him and his work, so we'll have to wait.
EDIT*** links are up, thanks morfic...
LIKE A BAWS
OK.... So here is my battery update....
16 hours off the charger...
48% left....
4.5 hours screen on time...
Ummm. Yeahhh... Lots of unnecessary CPU usage going on under the hood on ext4 I would say. That is a HUGE difference from what I typically see. Almost an hour if screen on time gained.
Cool
Dose it work on all kernels ???
Sent from my SGH-T889 using xda premium