Related
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
There is significant need for detailed information about filesystems here. Info is scattered in many topics.
My goal is to lead all thought concerning filesystem debate to this thread.
Lots of thought is given from the developers to choosing the correct one.
My idea is to start an detailed and technical only discussion about best suitable RFS replacement for SGS.
To start, I recall a blog post from Theodore Ts'o, one [if not main] of ext4 developers, who tested and compared write operations overhead on ext2/3/4 filesystems.
1. Thoughts by Ted - SSD’s, Journaling, and noatime/relatime
As a second reference I post Samsung's moviNAND™ (used in SGS) product info:
2. SAMSUNG Semiconductor - Products - Fusion Memory - MoviNAND
Third one, RFS product info:
3. SAMSUNG Semiconductor - Products - Flash - Flash Software
The first link should be the most interesting one. There are interesting results about overhead caused by journaling and comparisons of data written executing the same operations in these three filesystems.
Second and third ones should justify (or exclude!) the use of 'general purpose' filesystems on SGS.
Nice topic! Hopefully we can get some useful information out of this that can relate back to better lagfixes!
I'd first like to say: EXT3 doesn't make any sense. It has no advantages other than being a 'middle ground', and a fairly poor one at that. I don't think EXT3 is really relevant here.
So that leaves EXT2, and EXT4. In effect, EXT4 is just EXT2 with added options that are available, so it comes down to 'EXT simple' which is EXT2, and 'EXT features' which is EXT4. The features add to the overhead (how much? we need some way to test it!) and also reduce the speed in the case of journaling. The purpose of journaling is to remove the need for filesystem checks, which is fairly important to a lot of users who don't want their phone to be sitting at a black screen for minutes while booting.
To address the topics though, in regards to the Samsung recommendations - Samsung recommends we use RFS. I would personally discount any recommendations from Samsung at this point as being clueless, so unless other sources back up anything said by Samsung, it should probably be discounted!
As far as the Tso blog post, it is in regards to wear and tear on the SSD, and not in regards to speed. EXT4 adds both increased wear (up to 40% in a 'make clean' - how much does it add to normal Android operations, such as writing sqlite databases?) and decreases the speed (certain apps run slower). What the blog post is saying is that nothing bad will come from using EXT4, which is great, and let's us choose - since it doesn't say anything bad will come from using EXT2 either, except for the need for filesystem checks.
As far as fragmentation issues - the underlying MoviNAND is constantly shuffling around data by itself, so fragmentation is a bit of an unknown at this point in all cases.
So I'm gonna conclude (and hopefully someone will prove this wrong and give us more information) -
EXT2 : faster and less wear on the SSD and less overhead on the CPU, but requires disk checking on boot.
EXT4 : slightly slower and slightly more wear and slightly more CPU, but very fast boots.
I personally don't worry about flash wear , it takes many years for it to run out of write cycles by then you will have switched to new phone two or three times, that is the case for all SSD's during normal use, only exception would be server load but then you will be using premium SLC nand anyways, or intentionally running heavy simulated load 24/7 for the sake of killing nand
As for EXT as long as it is not crappy RFS , ext2 or 4 is ideal in my opinion.
RyanZA said:
As far as fragmentation issues - the underlying MoviNAND is constantly shuffling around data by itself, so fragmentation is a bit of an unknown at this point in all cases.
Click to expand...
Click to collapse
We should notice two fragmentation levels:
1) File system fragmentation (external and internal),
2) MoviNAND fragmentation, which is present, but nature and level is unknown.
In the context of ext2/3/4 choice I must disagree to some extent.
Nature of first one is well-known, and ext4 has been designed with lowering external file system fragmentation in mind, compared to ext2/3. This makes ext4 more viable option at this point, which should be noted.
There is no info given about MoviNAND layer fragmenation, nor wear-leveling methods. My conclusion (based on study of wear-leveling methods:
Micron TN-29-42: Wear-Leveling Techniques in NAND Flash Devices Introduction
) is that there might be significant amount of underlying layer fragmentation present, caused by file system not being 1:1 with physical media.
We might need to get more detailed information about this. The one and only mention about in-build wear leveling in MoviNAND I personally found is:
NAND technology changes invisible to the host
[...]
- Variation of NAND flash feature NAND block sizes, page sizes, planes, new features, MLC vs. SLC, wear leveling and ECC requirements
Click to expand...
Click to collapse
This is quite short.
RyanZA said:
EXT4 adds both increased wear (up to 40% in a 'make clean' - how much does it add to normal Android operations, such as writing sqlite databases?) and decreases the speed (certain apps run slower).
Click to expand...
Click to collapse
This seems to be the worst case scenario. Could anyone with knowledge explain the nature of 'make clean' operation?
Based on this study, average additional wear caused by amount of data written (only!) is no more than 15%, in the file system level.
We should consider write amplification, which level is unknown. Writing one byte in the file causes whole low-level block to be rewritten. Does this rewrite whole filesystem block? If so, it causes to rewrite all MoviNAND blocks containing data for one filesystem block.
We know that wear comes from write count per block, not write amount.
There are several improvements in ext4 which lower write count compared to ext2/3.
Here's some of them:
Persistent pre-allocation which prevents writing 0s to whole preallocated space,
Multiblock allocator, making allocating multiple blocks a single write operation,
Allocate-on-flush, delaying writes.
This adds up, decreasing number of writes.
//EDIT: Sorry for constantly editing this post, but I want to be as exact and understood I can be.
Shouldn't we not worry about file system defragmentation since it is only a big deal for spinning disk drives for their access times? whereas in SSD/NAND, access time isn't a real concern?
xan said:
We should notice two fragmentation levels:
1) File system fragmentation (external and internal),
2) MoviNAND fragmentation, which is present, but nature and level is unknown.
In the context of ext2/3/4 choice I must disagree to some extent.
Nature of first one is well-known, and ext4 has been designed with lowering external file system fragmentation in mind, compared to ext2/3. This makes ext4 more viable option at this point, which should be noted.
There is no info given about MoviNAND layer fragmenation, nor wear-leveling methods. My conclusion (based on study of wear-leveling methods:
Micron TN-29-42: Wear-Leveling Techniques in NAND Flash Devices Introduction
) is that there might be significant amount of underlying layer fragmentation present, caused by file system not being 1:1 with physical media.
We might need to get more detailed information about this. The one and only mention about in-build wear leveling in MoviNAND I personally found is:
This is quite short.
Click to expand...
Click to collapse
You can't just de-couple filesystem fragmentation from the underlying data fragmentation, I think. Or at least, the issue isn't all that cut and dried.
The major fragmentation changes in EXT4 over EXT2 is to ensure that the same file shares contiguous blocks. But, does this mean anything at all on top of MoviNAND?
NAND is random access - so 2 block file which has one block at the start of the disk, and one at the end, should perform identically to a 2 block file with the two blocks next to each other. However, this is where the practical comes in - If the MoviNAND has more than 1 chip with different channels or something, then having the 2 block file have block 1 on chip 1 and block 2 on chip 2 may actually be faster than having both blocks on chip 1.
Basically, fragmentation on the MoviNAND is not necessary the same as fragmentation on spinning media! And the MoviNAND isn't going to listen to where the filesystem tells it to put data, it provides a 'virtual table' that the filesystem sees, but unlike an old spinning disk, the table isn't what's actually going on.
So, I'm gonna say that We Know Nothin!
^my point, better explained
I do not have a lot of knowledge of file systems, but as explained here:
maenad.net/geek/di8k-debian/node29.html (i think that counts for ext4 as well)
Q: What is journaling?
A: It means you don't have to fsck after a crash. Basically.
This is useful, because it means that every time your screen whites out and crashes while choosing the right video card (Section 1.2.1), you don't have to sit through an entire filesystem check of every inode. The filesystem still fscks itself every X mounts or Y days, but doesn't put you through the entire wait every time you crash it.
To convert partition,s to the ext3 filesystem, you need to cleanly unmount them, boot something else (like the Debian CD you installed from -- see Section 6.2 on how to do this), and then, on a console, do:
tune2fs -j /dev/hdaX
wherein /dev/hdaX is the partition you want to add journaling to (hence the `-j' flag).
Click to expand...
Click to collapse
So when i'm correct, we are safe to use ext2 and loose the overhead, and take the fsck for granted.
Is there a raid solution for the external / internal sd cards available?
Also one point to consider is:
Are both the Internal SD (mmcblk0) and STL partitions MoviNAND? Or...
Is only the STL partitions OneNAND and the Internal SD is a separate device (MoviNAND)? Maybe RFS is necessary for OneNAND but not for MoviNAND?
RyanZA said:
You can't just de-couple filesystem fragmentation from the underlying data fragmentation, I think. Or at least, the issue isn't all that cut and dried.
Click to expand...
Click to collapse
Yes, this is correct. Furthermore I believe that file system fragmentation may lead to increased wear, depending on relation of file system and MoviNAND internal block sizes.
This actually depends on MoviNAND wear leveling algorithm, which is yet to be revealed.
RyanZA said:
The major fragmentation changes in EXT4 over EXT2 is to ensure that the same file shares contiguous blocks. But, does this mean anything at all on top of MoviNAND?
Click to expand...
Click to collapse
If this means something - we might actually add unneeded write count. If not, using these two file systems should result in the same amount of MoviNAND wear caused by fragmentation. We might be terribly wrong and introduce additional write counts. Why take the risk?
RyanZA said:
NAND is random access - so 2 block file which has one block at the start of the disk, and one at the end, should perform identically to a 2 block file with the two blocks next to each other.
Click to expand...
Click to collapse
In my opinion its too speculative. If it is true, it might increase linear operation speeds. There is a way to test it: write a large file and monitor MB/s in short time periods. If two or more performance levels are noticeable -> this makes this file to be written simultaneously, and your suspicions may be true. Although fragmenting file system in sake of exploiting this behavior is not a good idea.
What is sure, this puts excessive workload on controller, which should be always avoided.
RyanZA said:
Basically, fragmentation on the MoviNAND is not necessary the same as fragmentation on spinning media! And the MoviNAND isn't going to listen to where the filesystem tells it to put data, it provides a 'virtual table' that the filesystem sees, but unlike an old spinning disk, the table isn't what's actually going on.
Click to expand...
Click to collapse
Of course it isn't. But remember, with every additional write cycle in file system, there comes unknown amount of additional write cycles on MoviNAND. Also, with every single MoviNAND write, there comes full block (128KB? no idea here) read, ecc check, ecc recalc and rewrite. (Unless MoviNAND utilises copy-on-write, which is doubtful since it might increase wear)
What comes to my mind are first SSD's available on the market, some time ago. They were flawed, their random write times were unacceptable. Random write operations might not be that fast on MoviNAND as we might expect.
I think the fragmentation issue should be avoided, because in worst case scenario nor we lose or gain anything having less fragmentation.
RyanZA said:
So, I'm gonna say that We Know Nothin!
Click to expand...
Click to collapse
This however, is genuine statement
jbrugger said:
So when i'm correct, we are safe to use ext2 and loose the overhead, and take the fsck for granted.
Click to expand...
Click to collapse
Is it worth losing all features lowering write count and reducing fragmentation?
It might be better to use ext4 w/o journaling than ext2. This depends if the benefits of ext4 listed in one of my previous posts work without journaling.
xan said:
Is it worth losing all features lowering write count and reducing fragmentation?
It might be better to use ext4 w/o journaling than ext2. This depends if the benefits of ext4 listed in one of my previous posts work without journaling.
Click to expand...
Click to collapse
Isn't that solved by using the oclf over the voodoo fix?
xan said:
Yes, this is correct. Furthermore I believe that file system fragmentation may lead to increased wear, depending on relation of file system and MoviNAND internal block sizes.
This actually depends on MoviNAND wear leveling algorithm, which is yet to be revealed.
If this means something - we might actually add unneeded write count. If not, using these two file systems should result in the same amount of MoviNAND wear caused by fragmentation. We might be terribly wrong and introduce additional write counts. Why take the risk?
In my opinion its too speculative. If it is true, it might increase linear operation speeds. There is a way to test it: write a large file and monitor MB/s in short time periods. If two or more performance levels are noticeable -> this makes this file to be written simultaneously, and your suspicions may be true. Although fragmenting file system in sake of exploiting this behavior is not a good idea.
What is sure, this puts excessive workload on controller, which should be always avoided.
Of course it isn't. But remember, with every additional write cycle in file system, there comes unknown amount of additional write cycles on MoviNAND.
What comes to my mind are first SSD's available on the market, some time ago. They were flawed, their random write times were unacceptable. Random write operations might not be that fast on MoviNAND as we might expect.
I think the fragmentation issue should be avoided, because in worst case scenario nor we lose or gain anything having less fragmentation.
This however, is genuine statement
Click to expand...
Click to collapse
I got a bit lost as to what you were saying is impacting on what (<- I lost myself writing that too!)
This could be completely incorrect, since I don't know the low level details of MoviNAND! But, I'm going to try make a diagram so at least we'r all on the same page.
EDIT: red is for the 'fake' table, or the table that movinand shows to linux
green is for the 'real' table, or the actual layout of blocks on the physical disk
___1234____ would mean that all blocks are aligned in the proper order and are contiguous.
_2__3__1__4 would mean that the blocks are all over the place, with big gaps in between them, and in the wrong order.
A) File made up of 4 'blocks' sitting on EXT2, with each block labelled 1-4, and blank blocks labelled with an _
__3__2__1__4___
On a spinning disk, this would be horribly fragmented, and the disk would have to seek (spin) 4 times while reading the one file
However, the underlying MoviNAND real storage in terms of 'blocks' could look like this, purely due to chance (Remember, the MoviNAND is doing constant wear leveling - this means that after the device has been in use for awhile, it could be writing your next block anywhere!)
___123___4______
So even though it is very fragmented at a filesystem level, on the real physical media, it's not very fragmented at all!
B) Now we load up the same file onto EXT4. EXT4 thinks that the file is really fragmented (because all it sees is the 'fake' layout, it can't see the real layout!) so it goes ahead and fixes up the file for us! This is how the file looks to EXT4 now:
1234______________
Awesome, it's all nicely laid out! But wait, it had to move the blocks around to do this, so what may have happened to the underlying now?
____1_3__4______2_
It's actually worse than the fragmented EXT2, even though it's gone to all that effort of moving data around! This is also why running a 'defrag' on RFS might not actually help at all.
So basically, the issue isn't simple! I can't guarantee that this happens, since I don't really know how it all works, but I can almost guarantee you that going to any effort to align blocks on the virtual table isn't going to translate directly to the real physical disk!
So I'm going to conclude that EXT4s fragmentation routines are just as likely to hurt performance as they are to help it, with all of the overhead as well. If you do use EXT4, you should probably explicitly TURN OFF the defragmentation. Or at least, acknowledge that we don't know..
Well, I just want to add my 2 cents.
I used both OCLF and voodoo with OC kernel (thus I was experimenting with voltages and very often had to pull out the battery).
Never had data loss on OCLF as it was probabl negated by underliying rfs.
Once had data loss on voodoo, though older version (complete data loss - reboots (check fs I assume) did not help, as didn't just wiping data) and had to completely reflash.
Thus data loss is possible, up to a level where your phone would be almost unsuable (I had a lot of FC's, but could still call, for example). So, not sure if jounraling will actually help in case of data corruption.
RyanZA said:
Awesome, it's all nicely laid out! But wait, it had to move the blocks around to do this, so what may have happened to the underlying now?
Click to expand...
Click to collapse
I believe you are talking about Online Defragmentation, which according to this:
http://kernelnewbies.org/Ext4#head-38e6ac2b5f58f10989d72386e6f9cc2ef7217fb0
is
(This feature is being developed and will be included in future releases).
Click to expand...
Click to collapse
Yes, your drawings would be correct, but only when filesystem block size = MoviNAND block size.
RyanZA said:
I got a bit lost as to what you were saying is impacting on what (<- I lost myself writing that too!)
Click to expand...
Click to collapse
Yeh, sorry I'm not good at expressing my thoughts, even worse doing it in English.
What I'm trying to say is:
Given the number of unknown variables, there is a big probability that fragmentation is increasing write count, leading to increased wear.
Also, ext4 features decrease number of writes, decreasing wear.
dupel said:
Well, I just want to add my 2 cents.
I used both OCLF and voodoo with OC kernel (thus I was experimenting with voltages and very often had to pull out the battery).
Never had data loss on OCLF as it was probabl negated by underliying rfs.
Once had data loss (complete data loss - reboots (check fs I assume) did not help, as didn't just wiping data) and had to completely reflash.
Thus data loss is possible, up to a level where your phone would be almost unsuable (I had a lot of FC's, but could still call, for example). So, not sure if jounraling will actually help in case of data corruption.
Click to expand...
Click to collapse
To be honest, I'd attribute data loss to overclocking long before I'd attribute it to an EXT filesystem.
Moving around a lot of data and rebooting can also cause issues, as can numerous other things. From bug reports for OCLF, it basically comes down to the more different fixes and changes that a user tries, the more likely he is to report 'data loss'. All of the novice users I know who are using OCLF have never had any data loss issues (and there are tens of thousands of them at this point), so I'm fairly quick to attribute OCLF data issues to non-OCLF sources at this point, since after investigating it usually turns into 'well just before running oclf, I tried using Kies to flash froyo and it didn't work, and then I tried deleting stuff in root explorer, and then it.. '
I'm not discounting your issues though, but simply going by statistics that more people have had issues with overclocking than with OCLF. If anybody has any more info? Although this isn't really the place to post it - rather post it in the OCLF posts (or read through em, most of these issues have come up multiple times now! )
One fact is however that the rfs filesystem (that should be cooperating correctly with the underlaying system) does a worse job than ext4 or ext2 in the matter of speed.
In other words, the lag-fixes actually DO work.
Isn't it than safe to assume the underlaying system is just a 'normal' system, and stores like any other sd?
In that case the oclf over voodoo should be the best of both worlds.
xan said:
I believe you are talking about Online Defragmentation, which according to this:
http://kernelnewbies.org/Ext4#head-38e6ac2b5f58f10989d72386e6f9cc2ef7217fb0
is
Click to expand...
Click to collapse
I was referring more to a combination of Extents ("since an extent encourages continuous layouts on the disk" but also has a higher overhead afaik) as well as Multiblock allocation, which tries to ensure continuous layouts as well. I had thought that the online defragmentation was finished... but I guess not.
xan said:
Yes, your drawings would be correct, but only when filesystem block size = MoviNAND block size.
Click to expand...
Click to collapse
If filesystem block size != MoviNAND block size, then I'd think that a big performance boost may be in matching filesystem block size to movinand block size. If they aren't equal, then it would also be very important to ensure that they are at least aligned properly, else one filesystem block write could cause 2 movinand block writes.
More speculation here, but I believe that MoviNAND will rewrite an entire block if told to write data to disk. More diagrams!
Here is some data blocks that need to be written to disk. They are continuous, and 2 filesystem blocks = 1 movinand block.
___1234___
Here is the movinand blocks, however since 2 filesystem blocks = 1 movinand block, I'm going to use [12] and [34] to denote the blocks on movinand, since they cover 2 filesystem blocks
___[12]___[34]_
Here comes the interesting bit: the filesystem wants to write block 1 and block 2 to disk, so first it writes block 1. This causes the [12] block to be erased and rewritten with data that would contain new 1 and old 2. Then the filesystem writes block 2. This causes block [12] to be written again! This time with new block 1 and new block 2. So just because the blocks are continuous, doesn't mean we'r saving anything at all!
Although, MoviNAND is a 'smart' chip with a 'smart' controller, so it might have picked up that we asked the same block to be written twice and consolidated it into 1 write. Is MoviNAND really that smart? I personally doubt it!
As always, so much we don't know!
xan said:
Given the number of unknown variables, there is a big probability that fragmentation is increasing write count, leading to increased wear.
Click to expand...
Click to collapse
I don't think the probability is big. It could just as likely be leading to decreased wear, surely? The block size may even be the same. (I've been using a 4KB block size, we need to try and work out MoviNAND block size somehow)
RyanZA said:
As always, so much we don't know!
Click to expand...
Click to collapse
As stated before, i don't know alot about filesystems, but just a question, does this help?
http: //www.samsung.com/global/system/business/semiconductor/product/2010/4/16/078359S3C2450_51_16_IROM_ApplicationNote.pdf
(not allowed to post hyperlinks)
Sorry. Pasted wrong link...
http: //www.mobiletor.com/2010/09/07/samsung-launches-8gb-and-16gb-movinand-embedded-memory-chips/
About standards
RyanZA said:
To be honest, I'd attribute data loss to overclocking long before I'd attribute it to an EXT filesystem.
Moving around a lot of data and rebooting can also cause issues, as can numerous other things. From bug reports for OCLF, it basically comes down to the more different fixes and changes that a user tries, the more likely he is to report 'data loss'. All of the novice users I know who are using OCLF have never had any data loss issues (and there are tens of thousands of them at this point), so I'm fairly quick to attribute OCLF data issues to non-OCLF sources at this point, since after investigating it usually turns into 'well just before running oclf, I tried using Kies to flash froyo and it didn't work, and then I tried deleting stuff in root explorer, and then it.. '
I'm not discounting your issues though, but simply going by statistics that more people have had issues with overclocking than with OCLF. If anybody has any more info? Although this isn't really the place to post it - rather post it in the OCLF posts (or read through em, most of these issues have come up multiple times now! )
Click to expand...
Click to collapse
No, no. I think you misunderstood me. I never had data loss on OCLF (ext2), but had data loss on voodoo (ext 4).
And dont get me wrong Im not saying voodoo is worse than oclf or better, or not safe, etc. Just saying that even on "safer" fs you can have data corruption (and it doesn't really matter why (yes, it was my fault for playing too much with undervoltaging, thus having not responding phone)).
Which brings up the topic of "is it really safer (ext4 vs ext2)". And I dont know, as im not really a linux person, so just report that its possible and leave you to actually decide if its relevant, important etc.
So, it turns out the /preload partition is 500 megs of almost unused space, just to show us a video of Asphalt. So, how about turning it into swap space to almost double the effective amount of memory you have? To use this mod, you must be rooted, and have busybox installed. I recommend the stericson busybox installer https://play.google.com/store/apps/details?id=stericson.busybox&hl=en
I would like feedback on whether or not it actually speeds up the device, especially when running graphics-intensive games, and also effects on battery life.
How to install:
1.Be rooted.
2. Get busybox. If you don't already have it, you can get it here https://play.google.com/store/apps/details?id=stericson.busybox&hl=en
3. You must have init.d support. This is built into my NardROM but you can also flash the file attached to this post.
4. Flash the script installer, attached below. NOTE: This will wipe your /preload partition. You can make a nandroid before you perform this step but CWMR doesn't back up /preload. Back up anyway
5. If it's successful, you will see something like the following screenshot when you open a terminal window and execute "free". Notice the swap being used. If you don't have swap enabled it will read 0 available.
To disable the mod:
1. Delete the script from /system/etc/init.d
2. Reflash your Asphalt video from a backup
To disable init.d:
1. Delete /system/etc/install-recovery.sh, /system/etc/init.d (entire folder), /system/bin/sysinit, and /system/xbin/run-parts
Disclaimers:
Using nand memory as a swap can significantly reduce its life. Your phone's internal memory will wear out in years rather than decades
A lot of people argue using Android swap works against the built in memory management of the Dalvik machine
http://forum.xda-developers.com/showthread.php?t=1504774
This is awesome, glad to see people spending time on this device
Tappin' Typin'
'' /vendor '' also has 590,56 Mbyte of space..
what kind of data is there? there are some folders called ''multi_pose_face_landmark_detectors.3'' and ''yaw_roll_face_detectors.3'' ? is this the carrierIQ stuff?
After deleting everything on that partition it says 395,95 mb used, 194,61 mb free.
ludacris1 said:
'' /vendor '' also has 590,56 Mbyte of space..
what kind of data is there? there are some folders called ''multi_pose_face_landmark_detectors.3'' and ''yaw_roll_face_detectors.3'' ? is this the carrierIQ stuff?
After deleting everything on that partition it says 395,95 mb used, 194,61 mb free.
Click to expand...
Click to collapse
I think it's device-specific info for face unlock to compensate for various things like the angle you're holding the phone at and the distance away from your face. And if you'll look a little more closely, you'll find /vendor is symlinked from /system/vendor, it's not actually a separate partition. You should probably put those files back if you want face unlock to work.
Technically I just downloaded some ram
Sent from my SGH-I927 using xda app-developers app On Ics
FYI, this could be a potential source of serious slowness. Swap isn't anywhere near as fast as real RAM.
I wouldn't do this unless you're legitimately having issues you can directly attribute to running out of RAM. It may be useful as Android marches on and demands more and more RAM but for ICS we're already a good clip above the recommended specs.
Same thing I was thinking. I have more than enough RAM but if by some miracle we get something past JB that uses a lot of RAM I'll do this. Nice work on it though!
sent from my captivate glide running ICS (NardROM 0.4 Rooted)
roothorick said:
FYI, this could be a potential source of serious slowness. Swap isn't anywhere near as fast as real RAM.
I wouldn't do this unless you're legitimately having issues you can directly attribute to running out of RAM. It may be useful as Android marches on and demands more and more RAM but for ICS we're already a good clip above the recommended specs.
Click to expand...
Click to collapse
Waiting for the comparison,then
mewatashiakumoi said:
Waiting for the comparison,then
Click to expand...
Click to collapse
So with this hack having been out a couple months now, how are the reviews? Performance increase? Fewer slow downs?
pm2gonzales said:
So with this hack having been out a couple months now, how are the reviews? Performance increase? Fewer slow downs?
Click to expand...
Click to collapse
1) this is not a hack, this is a simple tweak
2) swap file is ALWAYS has a performance decrease effect, no matter what (desktop PC, android phone). The only reason of use is when the device has no enough RAM, and the background processes shall be kept elsewhere
3) android has it's own RAM managing system and methods, simply stick to that as only that will gives you the best performance and user experience
4) "slowdown" occurs when the device runs out of free RAM and starts closing background applications to give everything to the foreground app. When you close the heavy resource use foreground app witch caused android to close every possible background apps, the phone reloads them (launcher, live wallpaper, app drawer, widgets, user apps, etc...) and this is what causes a temporary slowdown, and this is unavoidable, no matter if you use swap or not.
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