No, you just need to remove a2sd. First of all from adb shell do "a2sd nocache" (it will restart); after reboot from shell do "a2sd nodata" (restart); and finally "a2sd remove".
Another option is to do it from A2SDGui
After this you can flash the script (.zip).

Originally Posted by lerkin

Yes I have rom without it.
I installed franciscofranco first, and everything was fine.
After it I flashed that script, android was starting for 5 minutes and after that it hanged up, I removed battery, started again and there were constant force closes of titanium backup, launcherpro and some android processes.

I tried to install only that Data2SD + Dalvik-cache2RAM script on fresh rom. It started, when it hanged on "preparing SD", after restart everything was fine, there was about 400 mb of free rom.
Interesting... Are those two scripts compatible?

Yes they are compatible. I'm running everything at the same time = 0 issues.

Sent from my LG-P500 using XDA Premium App

so to sum up i need to swap (dalvik-cache from ext3 and data on nand) ----> (dalvik-cache on nand and data on ext2/4) ????..My phone is already pretty fast with all the tweaks (thnx fransiscofranco) and all devs here.. the results must be apparent in real world application

Nice insights from everyone.

Although everyone prefers a different approach on things, I'll share my thoughts on this one.

IMO, I still haven't found any mod to make a STRIKING improvement in REAL LIFE performance(including this one). This is not because these mods don't actually work, it is because(once again) Optimus One is fast enough as it is(stock out of the box) and proves hard to spot improvements(for mere mortals that is). Now, with benchmarking, we can do controlled performance comparisons with different phones. On this part, moving data to sd, proves to boost the I/O performance of the phone dramatically. Of course this depends so much on you SD and again with which FileSystem the mod actually uses(2nd SD partition). Now on this matter, any thread you visit comparing ext2, ext3 and ext4 FS will let you in on one thing, "EXT2 is the fastest". That is heavily because of the lack of journaling(wherein the other two are journaling FS). There are still a lot of debate as on which is faster between ext3 and ext4 as ext4 has extended features that could theoretically improve it's performance way beyond ext3(and possibly ext2 - theoretically). Now since we may safely assume(also did some test and ext2 did come up faster than ext4) that ext2 is the FS of choice if we want speed, but what about journaling? I'm not really an expert but, AFAIK journaling serves only one purpose, and this is to maintain the FS integrity by making a journal(something like a logbook) about read/writes being done to the FS. This is very useful in case of power loss wherein data being stored gets cut-off half way through and therefore corrupts the data written which in the end can result in a damaged filesystem. Well, to deal with this, I have enforced a e2fsck(checks disk for errors with an option to fix everything automatically, if it does find any) on the SD ext(2nd) partition on every boot. Now, regarding dalvik-cache to RAM. There are many methods used to move dalvik-cache around(basically due to the lack of space and reduced performance when on SD), which includes moving it to SD(may result in reduced performance and decrease in SD card life), moving it to /cache(may result in market problems when downloading large apps) and so on. Now again, I'm not an expert on this but, I chose to move it on RAM basically because it suits the conditions used by dalvik cache. Easily accessible, fast, spacious and can withstand tremendous amount of read/write. Now I'm still testing the effects of rebuilding dalvik-cache contents on every reboot but so far, I haven't found any problems with it. As stated in the first post, this mod is still under development so some things might still change if found un-desirable.

No, you just need to remove a2sd. First of all from adb shell do "a2sd nocache" (it will restart); after reboot from shell do "a2sd nodata" (restart); and finally "a2sd remove".
Another option is to do it from A2SDGui
After this you can flash the script (.zip).

Nice info. Should add this to first post.

Originally Posted by ungaze

I have enforced a e2fsck(checks disk for errors with an option to fix everything automatically, if it does find any) on the SD ext(2nd) partition on every boot.

Very nice post dude.
How can one force an e2fsck on boot?

The mod already has it(just forgot to add the details in first post), but if you wan't to know how to do it manually(maybe without the mod) you could unpack the zip and study it or PM me.

Any info you guys can add would be very helpful. This is a great learning experience to all of us(specially me ).

Originally Posted by ungaze

Nice insights from everyone.

Although everyone prefers a different approach on things, I'll share my thoughts on this one.

IMO, I still haven't found any mod to make a STRIKING improvement in REAL LIFE performance(including this one). This is not because these mods don't actually work, it is because(once again) Optimus One is fast enough as it is(stock out of the box) and proves hard to spot improvements(for mere mortals that is). Now, with benchmarking, we can do controlled performance comparisons with different phones. On this part, moving data to sd, proves to boost the I/O performance of the phone dramatically. Of course this depends so much on you SD and again with which FileSystem the mod actually uses(2nd SD partition). Now on this matter, any thread you visit comparing ext2, ext3 and ext4 FS will let you in on one thing, "EXT2 is the fastest". That is heavily because of the lack of journaling(wherein the other two are journaling FS). There are still a lot of debate as on which is faster between ext3 and ext4 as ext4 has extended features that could theoretically improve it's performance way beyond ext3(and possibly ext2 - theoretically). Now since we may safely assume(also did some test and ext2 did come up faster than ext4) that ext2 is the FS of choice if we want speed, but what about journaling? I'm not really an expert but, AFAIK journaling serves only one purpose, and this is to maintain the FS integrity by making a journal(something like a logbook) about read/writes being done to the FS. This is very useful in case of power loss wherein data being stored gets cut-off half way through and therefore corrupts the data written which in the end can result in a damaged filesystem. Well, to deal with this, I have enforced a e2fsck(checks disk for errors with an option to fix everything automatically, if it does find any) on the SD ext(2nd) partition on every boot. Now, regarding dalvik-cache to RAM. There are many methods used to move dalvik-cache around(basically due to the lack of space and reduced performance when on SD), which includes moving it to SD(may result in reduced performance and decrease in SD card life), moving it to /cache(may result in market problems when downloading large apps) and so on. Now again, I'm not an expert on this but, I chose to move it on RAM basically because it suits the conditions used by dalvik cache. Easily accessible, fast, spacious and can withstand tremendous amount of read/write. Now I'm still testing the effects of rebuilding dalvik-cache contents on every reboot but so far, I haven't found any problems with it. As stated in the first post, this mod is still under development so some things might still change if found un-desirable.



Nice info. Should add this to first post.

Nice post mate. About ext filesystems, ext4 can be made faster than ext3 because of it's extended features like changing the way journalism is made etc, I've researched about it few days ago, but I'm still almost 100% sure even with tweaks it can't be made faster than ext2.
The rest of your post I agree with everything.

Ext4 Pros
- phone boot is faster
Ext2 Pros
- read time is faster
- write time is faster
- writting onti disk is lesser
- better battery life ( not really sure though

this are things that currently iknow, (far back on spica)

upon researching saw some feedback:
EXT2

-Recommended to move to EXT3
-Not Journaled
-POSIX access control
-EXT2 file system is the predecessor to the EXT3 file system. EXT2 is not journaled, and hence is not recommended any longer (customers should move to EXT3).

EXT3

-Most popular Linux file system, limited scalability in size and number of files
-Journaled
-POSIX extended access control
-EXT3 file system is a journaled file system that has the greatest use in Linux today. It is the "Linux" File system. It is quite robust and quick, although it does not scale well to large volumes nor a great number of files. Recently a scalability feature was added called htrees, which significantly improved EXT3's scalability. However it is still not as scalable as some of the other file systems listed even with htrees. It scales similar to NTFS with htrees. Without htrees, EXT3 does not handle more than about 5,000 files in a directory.

EXT4
-ext4 is an "advanced" version of ext3 with various improvements, basically an upgrade to the ext3 format.

not really sure if this has a bearing, but the battle between ext's were not yet concluded AFAIK

Last time, using the origin Dark Tremor script a2sd, it boost the I/O as well but after flash the performance script from francisco's thread the I/O back to normal?? anybody here flash the ungaze script and then Fancisco's (both Tweak.zip + local.prop and libsqlite.so) still keep the I/O score?

TIA.

^This should totally be true. . . . . . . . . .if we were to use it on a linux computer.

But we're not. Android may be very similar to linux but in reality it is also very different. First of all the mention about ext2 not having journaling sounds kinda redundant and repeating, and we are all well aware of that already. As I have said, and I quote(myself) "Now since we may safely assume that ext2 is the FS of choice if we want speed" and speed alone, so the hell with journaling . Just straightening the facts the we are comparing speeds, so every other feature comes next. So although your post is very informative, in the end, it all comes down to user preference. Speed or features?