Related
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.
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.
Hey everyone I just got my Galaxy Nexus from Bell and it isn nothing short of amazing. Screen is amazing compared to my milestone which is basically the international version of the Droid. So far, I have experienced lag only after loading up approximately 10-15 apps which I never do on a daily basis, so lag isn't an issue with this phone. Now, I do have a few issues.
1.) The wifi keeps disconnecting while I try to download the files for shadowgun
2.) The speakers are REALLY quiet.
3.) When I use advanced task killer the ram available is always under 300mb even if i kill all apps (is it optimized for ICS?)
4.) The multi touch barely works?? (Download a multitouch tester app... when you have one finger on the left side, the bottom right side wont detect your other finger?? Noticable in shadowgun, if you are moving, you can't look around via the bottom left of the screen...
Sent from my Galaxy Nexus using XDA App
mohitrocks said:
Hey everyone I just got my Galaxy Nexus from Bell and it isn nothing short of amazing. Screen is amazing compared to my milestone which is basically the international version of the Droid. So far, I have experienced lag only after loading up approximately 10-15 apps which I never do on a daily basis, so lag isn't an issue with this phone. Now, I do have a few issues.
1.) The wifi keeps disconnecting while I try to download the files for shadowgun
2.) The speakers are REALLY quiet.
3.) When I use advanced task killer the ram available is always under 300mb even if i kill all apps (is it optimized for ICS?)
4.) The multi touch barely works?? (Download a multitouch tester app... when you have one finger on the left side, the bottom right side wont detect your other finger??
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
1) Samsung phones tend not to have as good wifi reception as others. See if you can move closer to the router.
2) You can use an app like Volume+ to boost it a bit.
3) The available RAM should be about 600+ MB. The app is probably not optimised for ICS. Anyway there really should be no reason to clear apps from RAM unless it is actively using CPU.
4) Multitouch is fine for me using "Multitouch Test" app from the market.
Sent from my Galaxy Nexus using XDA App
mohitrocks said:
3.) When I use advanced task killer the ram available is always under 300mb even if i kill all apps (is it optimized for ICS?)
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
People worry too much about free RAM. As a professional programmer (though not Android), power user, and hacker of almost any device or computer I use, I can tell you that free RAM is wasted RAM. Does the device work well for you? Unless you have a specific reason to believe that lack of available memory is affecting your experience, you shouldn't worry about it.
I expect any device I use (computer, phone, tablet, server, anything) to be making as much use of the RAM available to it as possible. The operating system should be caching as much as it can in memory to increase performance and enhance your user experience. Caching will normally show up as unavailable RAM, but any decent operating system (even Windows, haha) will dump cache and make it available for applications as needed.
Please don't take this the wrong way... I only ever comment on such things try to be informative. I honestly wouldn't worry about it, unless you're experiencing a problem directly related to available memory, such as an app (or worse, the OS!) leaking memory and causing lags or the inability to open new apps, etc.
There's also the whole thing about how you shouldn't even be using a task killer... but there are already enough threads on XDA about that topic, so I won't get into that here
And finally I will say... I'm jealous! I haven't pre-ordered, because I want to bargin with Bell a bit, but I'll be heading to Bell tomorrow and I hope they have a Galaxy Nexus in stock!
lol @ wanting to have free RAM
that was very informative!. I bought mine from virgin in Toronto Eaton Centre,with $50 off because I told him I don't want the case.(They give free case on the pre-launched date,don't know about tomorrow tho.)gl with your bargin!
BootsSiR said:
lol @ wanting to have free RAM
Click to expand...
Click to collapse
Haha seriously.
Uninstall that task killer. Jesus do people not learn?
From everything I have read it seems that task killers only really interfere with Androids OS. I've never used one and the system seems to run fine =]
mohitrocks said:
Hey everyone I just got my Galaxy Nexus from Bell and it isn nothing short of amazing. Screen is amazing compared to my milestone which is basically the international version of the Droid.
Click to expand...
Click to collapse
Glad to see I am not the only one coming from a Milestone, haha. Leaps and bounds are the words that come to mind.
martonikaj said:
Haha seriously.
Uninstall that task killer. Jesus do people not learn?
Click to expand...
Click to collapse
Maybe he wants to have free RAM to run something else that consumes a lot of RAM? Did you ever think of that?
It's like making fun of someone who is trying to make money and asking them "why do you want money? You can't eat it! LOL..."
Well, no duh. The point of making money is to exchange it for things you want...
Chirality said:
Maybe he wants to have free RAM to run something else that consumes a lot of RAM? Did you ever think of that?
It's like making fun of someone who is trying to make money and asking them "why do you want money? You can't eat it! LOL..."
Well, no duh. The point of making money is to exchange it for things you want...
Click to expand...
Click to collapse
You also don't understand then I suppose. If he wants free RAM to run something else, that foreground app will take the RAM away from anything else in the background that is unnecessary (obviously the foreground app is more important). But this isn't something he has to do (or think about doing). The process is not like: working with app X, then deallocating memory manually, then starting app Y. Rather, it's using app X, then starting app Y and if Y needs memory that X is using, X disappears automatically and Y continues to run with its necessary resources.
As stated above, free RAM is wasted RAM. His (and many other's) quest to have as much free RAM as possible is a terrible goal to have that overall hurts the user experience. Freeing RAM for the sake of looking at a screen that tells you a certain number (omg higher # is better!!!!) isn't the proper way to be managing your device.
Anyways, this isn't a task killer thread. Several other topics were raised by OP.
martonikaj said:
You also don't understand then I suppose. If he wants free RAM to run something else, that foreground app will take the RAM away from anything else in the background that is unnecessary (obviously the foreground app is more important). But this isn't something he has to do (or think about doing). The process is not like: working with app X, then deallocating memory manually, then starting app Y. Rather, it's using app X, then starting app Y and if Y needs memory that X is using, X disappears automatically and Y continues to run with its necessary resources.
As stated above, free RAM is wasted RAM. His (and many other's) quest to have as much free RAM as possible is a terrible goal to have that overall hurts the user experience. Freeing RAM for the sake of looking at a screen that tells you a certain number (omg higher # is better!!!!) isn't the proper way to be managing your device.
Anyways, this isn't a task killer thread. Several other topics were raised by OP.
Click to expand...
Click to collapse
Ugh...I guess I'll have to keep using the analogy to get through to you...
So you ask the guy why he wants to make money, because "extra money is wasted money" since you can't eat the money, right? He tells you "so I can use the money to buy other things I need." Then you ask him, "why do you need to make more money to buy other things you need? Your house is worth a lot of money, if you ever need other things, just sell your house!"
Do you understand it now? The house is some background process that's important to the user, which the user wants to keep resident in memory. The other things are other apps that the user might run. If the user keeps running other apps, eventually Android will need to reclaim memory. But the user doesn't want to lose his house (i.e. doesn't want that important background process closed)! How to make sure Android doesn't do that? Here's an idea: why not have some extra money to spend on things (i.e. free up memory by killing the non-important apps so the important one doesn't get killed)?
This...really isn't that difficult of a concept to understand. I don't get why you feel the need to bash everyone who wants to kill processes. Sure, a lot of people use task killers for stupid reasons. But you can't always assume the worst in people. How do you know that he's killing processes just to stare at the free memory graph? You don't know that. You are just assuming it. You can't rule out this legitimate use for manual process management.
Your analogy is completely flawed. The analogy of getting more money in terms of RAM is by opening the phone and putting another RAM chip in the phone, not by freeing RAM through a task killer. Freeing RAM with a killer is just shifting money around. You're not creating more RAM by killing apps, you're just moving it around.
He has a limited income in this case. He can't open his phone and put more RAM in it. If you're on a limited income and can't just "make more money" then if you want to buy a new car and don't have money, you have to sell something. The thing is, he's trying to do it manually. The phone will handle it automatically. It will choose what will be killed in order to free RAM for the front-facing process.
So you're getting the same amount of RAM either way. You have 1GB in the entire system to use. Whether you manage it manually or let the phone do it automatically, you still have 1GB of RAM. The difference is, when you do it manually, you are less efficient than letting the phone handle it. You kill things unnecessarily, kill things you shouldn't, and you spend extra time doing it.
martonikaj said:
Your analogy is completely flawed. The analogy of getting more money in terms of RAM is by opening the phone and putting another RAM chip in the phone, not by freeing RAM through a task killer. Freeing RAM with a killer is just shifting money around. You're not creating more RAM by killing apps, you're just moving it around.
He has a limited income in this case. He can't open his phone and put more RAM in it. If you're on a limited income and can't just "make more money" then if you want to buy a new car and don't have money, you have to sell something. The thing is, he's trying to do it manually. The phone will handle it automatically. It will choose what will be killed in order to free RAM for the front-facing process.
Click to expand...
Click to collapse
Yes, I know it's not a perfect analogy. But how about you point out the flaw in my use case, rather than the flaw in my analogy?
The problem is exactly that the phone "will choose what will be killed in order to free RAM". What if you want to choose what gets killed and what doesn't, and not let Android decide? What if you know exactly what you want to keep resident in memory and what's unimportant and can be killed?
Just out of curiosity, wanted to know how the OP got his bell GN so fast?
Preordered mine and waiting impatiently!
Sent from my Nexus S using Tapatalk
Basically he's saying that he's not gaining anything by rearranging his RAM. The system will free up RAM from background processes if need be. Him freeing up RAM and having available RAM doing nothing is not beneficial.
Chirality said:
How about you point out the flaw in my use case, rather than the flaw in my analogy?
Click to expand...
Click to collapse
You analogy is flawed because you have no idea what you're talking about. Your use case makes no sense. If the background app staying in RAM is more important than the foreground app, why are you using the foreground app? It should be in the background because its less important apparently.
Whether you manage things manually or not, if you are using the foreground app actively (ahem, its in the foreground) and it needs more RAM, then the other apps will be killed. Everything but the foreground app will be 100% wiped from RAM if it needs to. You can't tell it not to. If you want things to act differently, you'll have to write your own OS that never kills a background process sitting in RAM. And it'll suck.
What you want, and what a task killer offers, are 2 completely different things.
I'll go ahead and set this link right here just in case you want some more learnin'.
---------- Post added at 11:32 PM ---------- Previous post was at 11:27 PM ----------
gdap said:
Just out of curiosity, wanted to know how the OP got his bell GN so fast?
Preordered mine and waiting impatiently!
Click to expand...
Click to collapse
Are they not available in-store to pickup? Maybe he did that rather than order for delivery.
martonikaj said:
You analogy is flawed because you have no idea what you're talking about. Your use case makes no sense. If the background app staying in RAM is more important than the foreground app, why are you using the foreground app? It should be in the background because its less important apparently.
Whether you manage things manually or not, if you are using the foreground app actively (ahem, its in the foreground), then the other app will be killed. If you want things to act differently, you'll have to write your own OS that never kills a background process sitting in RAM.
What you want, and what a task killer offers, are 2 completely different things.
Click to expand...
Click to collapse
Oh for crying out loud, how is this not getting through to you.
I'm not talking about killing the foreground app to make room for the background app. I'm talking about how to choose amongst the different background apps which one to kill.
Let's say that in order to make room for a foreground, Android has to kill one of two background apps. Most of the time you probably don't care which one it kills. But what if in this case the user cares very much, and want one to be killed but the other to stay in memory? Why not use a task killer to kill the unimportant one so the important one stays in memory? Is this seriously a hard concept for you to grasp?
Let's not get into personal attacks about knowledge here. I can assure you, I know more about memory management than you do, since I've seen the stuff you post around here. I've written my own garbage collectors, my own implementation of malloc/free/realloc that beats the glibc implementation in both performance and utilization. I know the pros and cons of most of the major memory allocator implementations out there, I know which allocator data structures are better at utilizing TLB cache and which ones have better worst-case performance. I know when to use compacting GC and when to use simple generational mark and sweep GC. You want to tell me I don't know what I'm talking about?
Chirality said:
Oh for crying out loud, how is this not getting through to you.
I'm not talking about killing the foreground app to make room for the background app. I'm talking about how to choose amongst the different background apps which one to kill.
Click to expand...
Click to collapse
You realize that a task manager doesn't offer you this utility. Killing something manually means that it will simply re-open and be there right after you're done killing it. If it wants to run, it will run.
Let's say that in order to make room for a foreground, Android has to kill one of two background apps. Most of the time you probably don't care which one it kills. But what if in this case the user cares very much, and want one to be killed but the other to stay in memory? Why not use a task killer to kill the unimportant one so the important one stays in memory? Is this seriously a hard concept for you to grasp?
Click to expand...
Click to collapse
If its that important, you won't put it in the background. Again Task Killers don't offer you this functionality actively. Killing something then quickly opening your foreground app is the most inefficient way to operate this, and still doesn't accomplish what you want with frequency. As I said above, the app will simply re-open in the background and take up the RAM again if it is supposed to be running (we're always talking about well-performing and properly formed apps). If you never want it running in the background, you need to uninstall it.
Let's not get into personal attacks about knowledge here. I can assure you, I know more about memory management than you do, since I've seen the stuff you post around here. I've written my own garbage collectors, my own implementation of malloc/free/realloc that beats the glibc implementation in both performance and utilization. I know the pros and cons of most of the major memory allocator implementations out there, I know which allocator data structures are better at utilizing TLB cache and which ones have better worst-case performance. I know when to use compacting GC and when to use simple generational mark and sweep GC. You want to tell me I don't know what I'm talking about?
Click to expand...
Click to collapse
No, I'm sorry sir. Most respectfully as possible, you are wrong on this topic. Really. I'm not gonna argue with you on any of these things anymore. Anyone who runs Android or has written apps or mods or ROMs will agree with me.
Your crazy-ass examples of apps running in the background that you MUST have open is not the real-world case for what we're discussing, and should never be considered a reason for anyone to ever install a task killer. People are not using them for these reasons, and they're aimlessly installing them for the wrong reason. It is 100% ruining the experience of Android to install an Auto Task Killer.
martonikaj said:
You realize that a task manager doesn't offer you this utility. Killing something manually means that it will simply re-open and be there right after you're done killing it. If it wants to run, it will run.
Click to expand...
Click to collapse
Where the hell are you getting this nonsense? If it's just a normal app, how the hell is it going to run again after you kill it? Do you even understand how Android activities, intents, and services work?
martonikaj said:
If its that important, you won't put it in the background.
Click to expand...
Click to collapse
Do you really have no idea how Android works? Any app that is not currently visible on screen are in the background. How are you going to prevent apps from being put into the background? Is it really too much to ask in today's multitasking operating systems to have two things that you care about running at the same time, one in the foreground and one in the background?
martonikaj said:
No, I'm sorry sir. Most respectfully as possible, you are wrong on this topic. Really. I'm not gonna argue with you on any of these things anymore. Anyone who runs Android or has written apps or mods or ROMs will agree with me. Your crazy-ass examples of apps running in the background that you MUST have open is not the real-world case for what we're discussing, and should never be considered a reason for anyone to ever install a task killer.
Click to expand...
Click to collapse
And that, then, just shows you have no understanding of how memory management works at all. The use case I described is the one of the most usual case there is in any multiprocessing environment. You think somehow Android is special with its ability to automatically manage memory? No, it's not. It's not radically different from any modern operating system with virtual memory. The main difference is that instead of swapping memory to disk, it just kills processes. The use case I describe is a straightforward case of multitasking on a virtual memory system. It's so basic that frankly I'm amazed you don't understand it. When you are running multiple processes at once, you want to be able to choose which ones are resident in memory and which ones are swapped (or, in Android's case, killed). The best way to do it under a memory constraint is simply to kill processes you don't care about. Really, really basic stuff. And you are supposed to be a computer science student?
Maybe this is all to abstract for you. Let me describe a simple real world case. You are traveling and you rely on Google Maps to get around. You want to keep it resident in memory so that you can always instantly open up Maps. But you also run a lot of other apps during your journey. Looking up stuff on the Internet, reading restaurant reviews, checking news and weather, etc. The thing is, these apps aren't all that important. You might open them once and never need them again that day. But if you open a certain number of these apps, say, 5, then Maps will get killed since it was the least recently used. How to prevent this? Simple. Everytime you are done with one of these non-essential apps, you just kill it. It's not important to have this app be instantly accessible the next time. Or you kill them after opening 2 or 3 or them. Whatever. The point is, by manually closing these apps, you ensure Android never runs low enough on memory to kill Maps, so Maps will always be resident in memory and can be pulled up at a moment's notice, which is what you want.
Is this such a crazy-ass thing to ask for? Is this not something normal that we do on our computers all the time?
Chirality said:
You are traveling and you rely on Google Maps to get around. You want to keep it resident in memory so that you can always instantly open up Maps. But you also run a lot of other apps during your journey. Looking up stuff on the Internet, reading restaurant reviews, checking news and weather, etc. The thing is, these apps aren't all that important. You might open them once and never need them again that day. But if you open a certain number of these apps, say, 5, then Maps will get killed since it was the least recently used. How to prevent this? Simple. Everytime you are done with one of these non-essential apps, you just kill it. It's not important to have this app be instantly accessible the next time. Or you kill them after opening 2 or 3 or them. Whatever. The point is, by manually closing these apps, you ensure Android never runs low enough on memory to kill Maps, so Maps will always be resident in memory and can be pulled up at a moment's notice, which is what you want.
Click to expand...
Click to collapse
This is almost a non issue. Maps will save its state before it gets killed.
Also, if you're using maps throughout your journey multiple times, and these other apps are being used only once, the other apps will be killed first. But you do have a point in the case where if you open maps, use a bunch of apps, and fill up your ram to the point where android starts killing your oldest processes first(maps in this case). But as I mentioned before, maps, along with many other apps, will save their state so its not a big deal.
Overall, you are correct in saying a user might want control over which apps are never killed, which is why they would use a task manager, but there are probably many people who use task managers for the wrong reasons.
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
I'm still pretty new to Android so I don't know what is normal, but why does the system use so much RAM when it is supposedly doing nothing? On my 2GB model, after a reboot it says that 1.2GB are free, but this soon drops to 900MB and continues to drop to 500 or 600MB, even if all apps are closed. Is this something I should just ignore and trust that tge Android system knows best and uses RAM appropriately?
kanagawaben said:
I'm still pretty new to Android so I don't know what is normal, but why does the system use so much RAM when it is supposedly doing nothing? On my 2GB model, after a reboot it says that 1.2GB are free, but this soon drops to 900MB and continues to drop to 500 or 600MB, even if all apps are closed. Is this something I should just ignore and trust that tge Android system knows best and uses RAM appropriately?
Click to expand...
Click to collapse
This must be the well-publicised Android 5.0.x memory leak.
DanielKennethRego said:
This must be the well-publicised Android 5.0.x memory leak.
Click to expand...
Click to collapse
Possibly, but my Memo Pad 7 seems much the same, and that's still on 4.4.2
If there is free memory then Android will let the apps sit in memory invisibly even after you have closed them - this way they will load faster next time you launch them. If the amount of free memory gets low Android will close some of those invisible apps. So that is normal, unless the amount of free RAM keeps decreasing while you do nothing with it - in that case there must be some bad memory leak.
In android, unused memory is kind of waste so system will allocate usage in a high percentage for efficiency.
DanielKennethRego said:
This must be the well-publicised Android 5.0.x memory leak.
Click to expand...
Click to collapse
graphO said:
If there is free memory then Android will let the apps sit in memory invisibly even after you have closed them - this way they will load faster next time you launch them. If the amount of free memory gets low Android will close some of those invisible apps. So that is normal, unless the amount of free RAM keeps decreasing while you do nothing with it - in that case there must be some bad memory leak.
Click to expand...
Click to collapse
xda_husky said:
In android, unused memory is kind of waste so system will allocate usage in a high percentage for efficiency.
Click to expand...
Click to collapse
kanagawaben said:
Possibly, but my Memo Pad 7 seems much the same, and that's still on 4.4.2
Click to expand...
Click to collapse
It is not a memory leak. All devices which are on papers 2GB are actually less than that. Take memory for example. My Nexus says 32GB but I get around 27GB. Same goes on with USB flash drivers/ pen drives.
Secondly, On Windows, you want to keep as much RAM available as you can so that programs have enough room to operate. When RAM fills up, Windows is forced to start using hard drive space as virtual RAM and hard drives are much slower than physical RAM.
This is not true for Android.
Android’s operating system has its own native handler for assigning RAM to apps and making sure that all of it is being used in the most optimal way. In fact, Android purposely tries to keep apps loaded into RAM for better performance. RAM is fast, remember? On mobile devices, every bit of speed is critical for a good user experience, so keeping apps in RAM is actually a good thing. So regardless how much your RAM is shown, it wouldn't affect your user experience unless the apps installed in your phone are more than RAM can handle at a time which means either update your phone with more RAM or uninstall your apps that you do not use!
Hnk1 said:
It is not a memory leak. All devices which are on papers 2GB are actually less than that. Take memory for example. My Nexus says 32GB but I get around 27GB. Same goes on with USB flash drivers/ pen drives.
Click to expand...
Click to collapse
That is not what OP is saying, at all.
DanielKennethRego said:
That is not what OP is saying, at all.
Click to expand...
Click to collapse
The OP says that the memory decreases over time. If you read my post again, i simply said as you more applications are loaded over time, the memory starts to decrease! This is what causes the memory to decrease and if you could use a bit of logic, you could have easily come to the conclusion
Hnk1 said:
The OP says that the memory decreases over time. If you read my post again, i simply said as you more applications are loaded over time, the memory starts to decrease! This is what causes the memory to decrease and if you could use a bit of logic, you could have easily come to the conclusion
Click to expand...
Click to collapse
...And that is not what I quoted in my reply, is it?
DanielKennethRego said:
...And that is not what I quoted in my reply, is it?
Click to expand...
Click to collapse
Sometimes it's good to swallow some pride and in that there's more dignity. I explained everything from bits and pieces and I'm sure OP can conclude it unlike you.
Do not hesitate to quote me for any query. Always welcomed
Hnk1 said:
It is not a memory leak. All devices which are on papers 2GB are actually less than that. Take memory for example. My Nexus says 32GB but I get around 27GB. Same goes on with USB flash drivers/ pen drives.
Secondly, On Windows, you want to keep as much RAM available as you can so that programs have enough room to operate. When RAM fills up, Windows is forced to start using hard drive space as virtual RAM and hard drives are much slower than physical RAM.
This is not true for Android.
Android’s operating system has its own native handler for assigning RAM to apps and making sure that all of it is being used in the most optimal way. In fact, Android purposely tries to keep apps loaded into RAM for better performance. RAM is fast, remember? On mobile devices, every bit of speed is critical for a good user experience, so keeping apps in RAM is actually a good thing. So regardless how much your RAM is shown, it wouldn't affect your user experience unless the apps installed in your phone are more than RAM can handle at a time which means either update your phone with more RAM or uninstall your apps that you do not use!
Click to expand...
Click to collapse
I must say, although most of what you say is true, having less free ram absolutely does have a negative effect on user experience. My browser tends to crash, non-intensive games face lag spikes and the general UI stutters. Is this due to Android or Asus' tweaks to Android doing a poor job at managing ram? I don't doubt that in a perfect scenario with a perfect OS, what you said holds true.
I've not had good experience with the RAM so far. My browser tabs fall out of memory more than my cheap 1GB phone. It's rather disappointing. Even just switching between 2 or 3 tabs and going back to a tab after a few seconds and it's already fallen out.
aloy99 said:
I must say, although most of what you say is true, having less free ram absolutely does have a negative effect on user experience. My browser tends to crash, non-intensive games face lag spikes and the general UI stutters. Is this due to Android or Asus' tweaks to Android doing a poor job at managing ram? I don't doubt that in a perfect scenario with a perfect OS, what you said holds true.
Click to expand...
Click to collapse
damian5000 said:
I've not had good experience with the RAM so far. My browser tabs fall out of memory more than my cheap 1GB phone. It's rather disappointing. Even just switching between 2 or 3 tabs and going back to a tab after a few seconds and it's already fallen out.
Click to expand...
Click to collapse
Yes as I mentioned before, if the apps which are preloaded are more than RAM can handle, you'd surely see a lag but killing background apps wouldn't be of much help either unless your RAM memory has too many preloaded apps already which is affecting performance of your phone. If you are rooted, apps like greenify / titanium can hibernate / freeze apps which take up memory and usually this helps in better user interface but again many other argue the opposite.
Are you using Asus Browser ? If yes, I'd suggest to use chrome as your default browser because Asus Browser is not only slow but also it drains a lot of battery. This has been proven extensively and even reviewed on different websites including gsmarena.
Basically Nexus provides pure Android interface which every manufacturer tweaks a bit according to their own needs. Usually this tweaking means more memory usage(Ram) by system UI. This is one reason that Samsung's touch wiz lags a lot on lower end phones but the same hardware runs smooth without touchwiz. The reason is Samsung has lots of tweaks in system UI .
Some browsers conserve memory by only keeping the tab used in memory and rest are loaded when you switch them. They aren't preloaded but usually this option is available in settings to preload pages which would use more memory.
I have preordered the device with 4gb so I'm afraid I can't compare your device with mine in this regard.
Kindly tell me which browsers are you using so I can comment further
Hnk1 said:
Yes as I mentioned before, if the apps which are preloaded are more than RAM can handle, you'd surely see a lag but killing background apps wouldn't be of much help either unless your RAM memory has too many preloaded apps already which is affecting performance of your phone. If you are rooted, apps like greenify / titanium can hibernate / freeze apps which take up memory and usually this helps in better user interface but again many other argue the opposite.
Are you using Asus Browser ? If yes, I'd suggest to use chrome as your default browser because Asus Browser is not only slow but also it drains a lot of battery. This has been proven extensively and even reviewed on different websites including gsmarena.
Basically Nexus provides pure Android interface which every manufacturer tweaks a bit according to their own needs. Usually this tweaking means more memory usage(Ram) by system UI. This is one reason that Samsung's touch wiz lags a lot on lower end phones but the same hardware runs smooth without touchwiz. The reason is Samsung has lots of tweaks in system UI .
Some browsers conserve memory by only keeping the tab used in memory and rest are loaded when you switch them. They aren't preloaded but usually this option is available in settings to preload pages which would use more memory.
I have preordered the device with 4gb so I'm afraid I can't compare your device with mine in this regard.
Kindly tell me which browsers are you using so I can comment further
Click to expand...
Click to collapse
Using Chrome. That's the whole point of having more memory, so they don't have to be reloaded when switching.
If I had 10 tabs open and switching back and forth over a long period of time, this is understandable. Not 2 or 3 tabs and switching between two tabs within 10 seconds. Defeats the entire purpose of having 2GB of RAM. The same thing happens switching between apps. Many of them fall out of memory within just a few seconds of switching back and forth. My 1GB phone does better than this. Something to do with whatever memory management Asus has set up.
damian5000 said:
Using Chrome. That's the whole point of having more memory, so they don't have to be reloaded when switching.
If I had 10 tabs open and switching back and forth over a long period of time, this is understandable. Not 2 or 3 tabs and switching between two tabs within 10 seconds. Defeats the entire purpose of having 2GB of RAM. The same thing happens switching between apps. Many of them fall out of memory within just a few seconds of switching back and forth. My 1GB phone does better than this. Something to do with whatever memory management Asus has set up.
Click to expand...
Click to collapse
I understand your frustrations and it could be Asus related buy I think this is how chrome operates generally so it's the browser in my opinion. I suggest you use dolphin browser (not mini version) because it usually preloads pages on my devices and it is fast as well but I usually use it for flash support only. I prefer opera classic (now opera) on my phone with chrome . On my tab, I use chrome only. It always works for me and it's Asus made. Tell me what you think of it after using it a bit . I like chrome for its sync support which is very simple and helpful.
Hnk1 said:
Yes as I mentioned before, if the apps which are preloaded are more than RAM can handle, you'd surely see a lag but killing background apps wouldn't be of much help either unless your RAM memory has too many preloaded apps already which is affecting performance of your phone. If you are rooted, apps like greenify / titanium can hibernate / freeze apps which take up memory and usually this helps in better user interface but again many other argue the opposite.
Are you using Asus Browser ? If yes, I'd suggest to use chrome as your default browser because Asus Browser is not only slow but also it drains a lot of battery. This has been proven extensively and even reviewed on different websites including gsmarena.
Basically Nexus provides pure Android interface which every manufacturer tweaks a bit according to their own needs. Usually this tweaking means more memory usage(Ram) by system UI. This is one reason that Samsung's touch wiz lags a lot on lower end phones but the same hardware runs smooth without touchwiz. The reason is Samsung has lots of tweaks in system UI .
Some browsers conserve memory by only keeping the tab used in memory and rest are loaded when you switch them. They aren't preloaded but usually this option is available in settings to preload pages which would use more memory.
I have preordered the device with 4gb so I'm afraid I can't compare your device with mine in this regard.
Kindly tell me which browsers are you using so I can comment further
Click to expand...
Click to collapse
Using Firefox, I read about the stock browser issues before getting the phone.
Clearing ram using the built in booster appears to help with performance, although it could be a placebo, and it's certainly less pronounced than on my previous phone with only 1GB of ram.
I have greenify'd/frozen a lot of apps, including some of the Asus bloatware. No comment on improved performance though.
Overall, I'm happy with the performance but low ram still seems to bother me, although such scenarios are rare.
aloy99 said:
Using Firefox, I read about the stock browser issues before getting the phone.
Clearing ram using the built in booster appears to help with performance, although it could be a placebo, and it's certainly less pronounced than on my previous phone with only 1GB of ram.
I have greenify'd/frozen a lot of apps, including some of the Asus bloatware. No comment on improved performance though.
Overall, I'm happy with the performance but low ram still seems to bother me, although such scenarios are rare.
Click to expand...
Click to collapse
I think you are more worried about RAM that is left in your memory rather than actual performance. This can happen especially if you had very high expectations from this phone. According to ASUS, this is a midrange phone on their website. Not a flagship if you are hoping!
I suggest check the performance by installing some heavy graphic games and see if it lags or not. I am sure that would be the best way to find out!
Good Luck!
The browser pages redrawing is almost certainly the lollipop memory leak. I don't have a zenfone 2 yet, but my nexus 7 had this problem up until the release of 5.1, so hopefully Asus updates to that soon.
i notice when i uninstalled clean master..my ram always on 1 gb free unlike before it stays at 650..700 free...notice my phone is even faster now
TOT_tomdora said:
The browser pages redrawing is almost certainly the lollipop memory leak. I don't have a zenfone 2 yet, but my nexus 7 had this problem up until the release of 5.1, so hopefully Asus updates to that soon.
Click to expand...
Click to collapse
Correct, thank you for finally making that point clear as it's the main reason, which clearly isn't Asus' fault.
pato2015 said:
i notice when i uninstalled clean master..my ram always on 1 gb free unlike before it stays at 650..700 free...notice my phone is even faster now
Click to expand...
Click to collapse
An ironic, yet awesome find pato!:thumbup: Be sure to relay this to the other places on the net that you're involved with that pertains to the Zenfone 2.
Sent from the Ace's MB865 using Tapatalk