Develop Bugs

[UTIL][OUTDATED] One Click Lag Fix 2.0

[size=+2]This version is now deprecated in favor of the 2.0 APK version. Please see this link: http://forum.xda-developers.com/showthread.php?t=784691[/size]
This version is not recommended for use any longer.
Details about what this fix does:
Creates a VIRTUAL EXT2 filesystem inside the stock RFS filesystem on the internal SD card, with a 4KB block size. This means that this lag fix creates a buffer between the real filesystem and the android system. This buffer should reduce the amount of disk I/O required for all operations by utilizing EXT2 buffering, as well as not writing file access times to disk, etc.
Folders that are currently supported:
/data/data
/data/system
/data/dalvik-cache
/data/app
/data/app-private as a symlink to /data/app/app-private
/dbdata/databases is not supported. It appears to be ROM backed, and can cause problems if overwritten.
Benefits over version 1
1.5GB of application data available, with no data loss.
e2fsck of the EXT2 partition on each boot.
Correct busybox version included! YES!
/app and /app-private directory included in the fix for faster application installs.
/dbdata/databases included in the fix, expected to give a big performance boost for apps that use it.
Mounts instead of symlinks for extra performance as OS does less work (about 100 or so more quadrant).
Benefits over other lag fixes
Open source, with full comments and ease of editing.
Works on any and all firmware versions, including any yet unreleased froyo versions (that don't change file structure).
Credits
Big thanks to mimocan for putting us all on the right track in how to sort out lag problems!
Big thanks to ykk_five for showing us all how well loopback filesystem mounting works!
Big thanks to cyanogen mod for e2fsck
Requirements for One Click Lag Fix 2.0
Rooted phone - http://www.addictivetips.com/mobile...t-samsung-galaxy-s-i9000-with-a-single-click/
Windows computer with SGS Drivers (Samsung Kies), or the ability to read through the batch file and run it yourself.
(Beta Release) The ability to reflash your device if something goes wrong.
No other lag fix installed. If you installed One Click Lag Fix 1.0, then use the uninstall function which came with that lag fix before running this lag fix. (Untested but assumed to be working, please help out here.)
1.5GB of freespace on Internal SD Card for swap files while the fix is working (/sdcard).
"Internal phone storage" in Settings->SD Card must read greater than 500mb (0.5GB) of free space.
How to run One Click Lag Fix 2.0
Place your phone into USB debugging mode: Settings->Applications->Development
Attach your device to your computer. Do not mount the drives.
Download the attached ZIP file.
Unzip to a folder of your choice.
Double click "lagfixme.bat".
Don't double click "unlagfixme.bat".
Wait for it to complete.
You will need your phone to be unlocked when it runs the script, so that you can accept the permissions request that will appear on your device.
How to remove One Click Lag Fix 2.0
Double click "unlagfixme.bat"
Wait for it to complete.
Known Issues For All Versions
Some custom firmwares use up all available space in /system. This fix requires some libraries to be placed in /system/lib. These libraries are used to create the filesystem properly, and to check it for errors on every boot.
If your firmware does not have the available space (around 1mb) in /system, do not use this fix! Your phone will not boot and will have to be restored from backup / reflashed.
Current known firmwares with this issue: None yet. Please provide the firmware version+mods if you encounter this issue. It will show up as an out of space error in the log, under 'Copying libraries'.
Known Issues 2-1, 2-2
Paid apps from the market have issues.
Google maps and other pre-installed ROM-backed applications have issues.
2-3 Changes from 2-2
/dbdata has been removed. This fixes maps issues.
/app-private is now a symlink to /app/app-private. This fixes paid apps issues.
Alternate installation methods for similar fixes
Tayutama has made an update.zip version that is easy to install - http://forum.xda-developers.com/showpost.php?p=7632258&postcount=208
Chainfire has a .NET version of this fix with some nice features - http://forum.xda-developers.com/showthread.php?t=751513

Frequently Asked Questions
Q: My apps are force closing while this fix is running, and I can't use my phone!
A: By design. The script has backed up/copied your apps over to the internal SD card (remember the requirement about 1.5GB of free space on the SD card?). It is now overwriting them with a 1.5GB file. As the file overwrites an app that is trying to do something, it will probably force close. This is normal.
Closing all running apps, and removing widgets before running this fix can make the process much smoother, though.
Q: The script can't transfer files to my phone / The script can't run / Help help I'm dieing!
A: Read the first post again.
Q: My paid apps from the market don't show up.
A: I will hopefully have a fix for this sooner or later. Hold tight! It's in the known issues. I don't have access to paid apps, so I can't test this.
Q: Does this need busybox?
A: No, busybox is included.
Q: I only have 200mb of free space now! What gives?
A: The lag fix has made a 1.5GB file, and is storing all of the data inside there. The side effect is that the free space meter is now incorrect. Sorry, this can't be helped.
You can check real free space by using ADB like this:
Code:
adb shell
su
busybox df -h
Q: When I use a backup tool, the backup is now 1.5GB big! It's taking forever!
A: The backup tool isn't designed to work with this fix. It will work, it just won't work well. Hopefully this fix will be short lived, and either Samsung will give us a new update, or someone will give us a good custom firmware that can natively mount what we need, where we need it. Or someone might come out with a better backup manager. Until then, we suffer.
Q: Will a reflash wipe this fix?
A: Yes, a reflash will wipe everything this fix did.
Q: Can this brick my phone?
A: If you know how to get to the download mode from power off (hint: volumedown+home+power), then almost nothing short of throwing your phone off a tall building can actually brick it. If you can't do this though, or don't know someone who can, then you're better off waiting for samsung to release a fix. Anything that moves files around on your device has the potential to break things, and this fix has no QA department.
Q: Why is /dbdata not included in your fix, but other people have included it?
A: Other people have included it in the same way my 2-2 fix includes it. However, /dbdata is ROM backed. This means that the real files are on ROM, and only the changes appear in the /dbdata folder. When copying or moving files from this folder, you would need to specify each folder by exact name to ensure that it was copied across, and each firmware can have their own names. (This is because RFS wildcard will not catch an unused ROM backed file.) In some cases, you can get lucky and have this work perfectly because you have already used all the files in /dbdata. There is no fail safe method to do this though, and /dbdata does not make a big difference to performance. (It is already on NAND flash.) If you want to try your luck, v2-2 is still available.
Q: Why does this lag fix work? Is it slowly destroying my phone?
A: Let's say an application counts from 1 to 10, and writes the value each time to disk.
Stock:
1 -> App tells RFS to write 1 to disk -> RFS writes 1 to disk -> RFS writes journal saying to changed the value on the disk.
2 -> App tells RFS to write 2 to disk -> RFS writes 2 to disk -> RFS writes journal saying to changed the value on the disk.
..
9 -> App tells RFS to write 9 to disk -> RFS writes 9 to disk -> RFS writes journal saying to changed the value on the disk.
10 -> App tells RFS to write 10 to disk -> RFS writes 10 to disk -> RFS writes journal saying it changed the value on the disk.
Total physical disk writes: 20. Speed: SLOW! Wear and tear on disk: HIGH!
Lag Fix:
1 -> App tells EXT2 to write 1 to disk -> EXT2 stores 1 in RAM.
2 -> App tells EXT2 to write 2 to disk -> EXT2 stores 2 in RAM.
..
9 -> App tells EXT2 to write 9 to disk -> EXT2 stores 9 in RAM.
10 -> App tells EXT2 to write 10 to disk -> EXT2 stores 10 in RAM.
..
EXT2 tells RFS to write 10 to disk -> RFS writes 10 to disk -> RFS writes journal saying it changed the value on the disk.
Total physical disk writes: 2. Speed: FAST! Wear and tear on disk: LOW!
This isn't exactly what is happening, but it gives you the general idea.
Q: Can this mod work on other Android devices? Would we see a performance boost on them as well? If not why is it limited to the Galaxy S?
A: SGS has very very good hardware, but it has some parts of it's hardware poorly implemented. The filesystem that samsung chose to use is custom-built using FAT32 as a base, RFS. It has a lot of the problems that FAT32 has, and should have been left back in the 90s, or even the 80s.
One of the big issues with it is how it handles multiple requests - it blocks. It blocks everything. When your mail app wants to read the mail you just tried to view, but your twitter app is busy writing a new tweat it just received, your mail app is forced to wait.
This is bad, but it could be worse! And it is... your twitter app didn't just get one tweat, it got 50 tweaks. It is busy writing the tweats one by one to the filesystem. This would be fine, since all modern filesystems will buffer writes, so instead of writing each one at a time, they will batch them together and write it as a big chunk. Uh oh - RFS does no buffering at all! After each write, it will also write an update to the grafted-on journal system. Guess what happened to your mail you were trying to view while all this happened? It 'lagged' and you got a black screen for half a second, before the mail popped into view.
Luckily the hardware on the device is so good that you usually don't even notice the problem until you have a lot of apps running, all writing their updates when you unlock the phone.
This is mostly speculation based on experiments done on RFS -- RFS is closed source, and we have no idea if the problems are just badly set settings (such as a block size that is too small), coding bugs in the implementation, or if RFS is just really that badly designed.
This fix just grafts a buffer on top of the RFS filesystem, using a very very simple and fast filesystem, EXT2. It fixes most of the issues by writing to RFS as seldom as possible.
So no, this fix won't fix other devices, since they're already running quite close to maximum speed. The SGS at stock is running nowhere near maximum speed, and this lag fix takes it a bit closer. You could probably speed up other devices by tweaking the filesystem settings to give them a big buffer or similar, but it isn't really needed. (I haven't actually tried to put an EXT2 onto any other Android phone, as I don't have any other Android phone, so this is just speculation.)
Q: My phone is fast now!
A: Yeah.

Oh, awesome. I managed to post this in the wrong forum. Doh!
Could a moderator please move this to Android Dev sub forum?

haha looks awesome dude but you are correct, wrong section im gonna try it now, will report in 5 mins!

A few people in the other thread said they had the first lag fix working on the captivate. Anything that might change that with this release? I came to download the old one, and here a new one is

abra-cadabra...
*POOF*
Done!

E_man5112 said:
A few people in the other thread said they had the first lag fix working on the captivate. Anything that might change that with this release? I came to download the old one, and here a new one is
Click to expand...
Click to collapse
The old one is still here. Nothing has changed that should stop it working on the captivate though, but it is completely untested. Use the 1.0 (which has had a lot of testing) until this one has been put through the paces.

sirphunkee said:
abra-cadabra...
*POOF*
Done!
Click to expand...
Click to collapse
Thanks.

RyanZA said:
The old one is still here. Nothing has changed that should stop it working on the captivate though, but it is completely untested. Use the 1.0 (which has had a lot of testing) until this one has been put through the paces.
Click to expand...
Click to collapse
E_man5112 said:
A few people in the other thread said they had the first lag fix working on the captivate. Anything that might change that with this release? I came to download the old one, and here a new one is
Click to expand...
Click to collapse
I'm running the manual ext2 fix with Q scores 2000+. I'll try 2.0 Util tonight and post feedback....

Someone got some benchmarks?
Maybe for xxjp3? I only reach 1900 in quadrant.. /:
Sent from my GT-I9000 using Tapatalk

gonna test report in 5minutes

RyanZA said:
The old one is still here. Nothing has changed that should stop it working on the captivate though, but it is completely untested. Use the 1.0 (which has had a lot of testing) until this one has been put through the paces.
Click to expand...
Click to collapse
I'm in the process of flashing back to stock on my Captivate so I can give this a legit test. I'll report back here and let you know how it goes. Assuming my Captivate doesn't melt I'll update my OP from the thread about the original fix in the Captivate section!

About what lag is this?
Sent from my HTC Desire using XDA App

Dominik06 said:
Someone got some benchmarks?
Maybe for xxjp3? I only reach 1900 in quadrant.. /:
Sent from my GT-I9000 using Tapatalk
Click to expand...
Click to collapse
Benchmarks are roughly the same as 1.0. You can expect about 100 points more on average though, at least on my phone.

I just removed the V1 version and finished the V2.
It finally finished and rebooted the phone. now it tells me my internal memory storage is full. None of my Widgets will load.
Looking i see only 14MB free in internal storage.
thoughts?

Zilch25 said:
I'm in the process of flashing back to stock on my Captivate so I can give this a legit test. I'll report back here and let you know how it goes. Assuming my Captivate doesn't melt I'll update my OP from the thread about the original fix in the Captivate section!
Click to expand...
Click to collapse
Just as long as you point out that this fix isn't heavily tested yet!

RyanZA said:
Just as long as you point out that this fix isn't heavily tested yet!
Click to expand...
Click to collapse
Oh I know, I'm going to emphasize that heavily, lord knows I don't want to get stuck on tech support all night

clubtech said:
I just removed the V1 version and finished the V2.
It finally finished and rebooted the phone. now it tells me my internal memory storage is full. None of my Widgets will load.
Looking i see only 14MB free in internal storage.
thoughts?
Click to expand...
Click to collapse
Thoughts? That's bad.
You should be seeing roughly 215mb free. Did you see any errors in the log at all?

Everything is working fine for me. First reboot after lagfix had some problems with downloading apps from market, but after a second reboot it got fixed.
"Biggest" problem now, is just the phone stating that my internal phone storage is too low, with an icon on notification bar that I cannot remove. Already deleted some .bak from /data folder, any more tips what I can delete to get rid from this message?
Regarding the fix. apps are indeed much more snappier, no lag on the system when installing apps from market, and overall if the phone would continue like this for the next 48 hours, lag fix form me is solved. I had some problems after some 24h, with some lag, even with the previous version of the lag fix.

clubtech said:
I just removed the V1 version and finished the V2.
It finally finished and rebooted the phone. now it tells me my internal memory storage is full. None of my Widgets will load.
Looking i see only 14MB free in internal storage.
thoughts?
Click to expand...
Click to collapse
Looking through my old V1 remove script, I believe I was leaving behind the .bak files! Nastyyy... I'll update V2 to remove those if they're there on install. Will hopefully clear up any problems.

[DOC][DEV] More free space on /data for the Hero

Hey Devs,
As you may have noticed, I recently released a ROM with 276 MB free space on /data.
I accomplished this by using the MTD hack discovered by firerat and lbcoder.
It changes the kernel cmdline and includes addresses where the partitions are located.
This way, we are able to change the sizes.
That's exactly what I did.
The bad thing is that you need a recovery with a cmdline, which matches the ROM's boot.img's one!
So, a user needs to flash a recovery first and can then flash the ROM after a reboot into the new recovery.
Now, if the user wants to change his ROM to something else, he will need to revert the recovery.
It would be a lot easier if some other developers here would be interested in the MTD hack, so there is no need to revert.
I hope that some other developers will jump on the bandwagon now.
Here is the command I use for creating boot.img's, with modified partition sizes:
Code:
mkbootimg --kernel kernel --ramdisk ramdisk --cmdline 'mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)' -o boot.img --base 0x19200000
This reduces the /cache partition to 4 MB and makes /data as big as possible (the space which is left).
Now, the Market would normally fail to download huge APKs, because /cache is so small.
The problem can be easily solved by symlinking /cache to /data/cache and mounting the native cache partition on /dev/cache.
This can be done even without modifying the ramdisk, just do it in a script which runs before the Android frameworks start, like a2sd scripts.
Here are the necessary commands:
Code:
mount -o rw,remount /
umount /cache
rm -rf /cache
mkdir /data/cache
ln -s /data/cache /cache
mkdir /dev/cache
mount /dev/block/mtdblock4 /dev/cache
chmod 777 /data/cache
mount -o ro,remount /
Regarding the recovery:
Klothius from the Sapphire section created an update.zip which automatically patches the current recovery to use the provided cmdline.
You can find it here and include it in your instructions:
http://www.megaupload.com/?d=FY6CBAEE
I hope this little documentation will help you and will make you interested in doing this for your ROM.

Nice work. We'll look at implementing this into the next FroydVillain release. My only reservation would be keeping a wee bit more space on /cache than 4MB since our OTA app uses it. We could always hack it to use a dir on /data I suppose.

Hacre said:
Nice work. We'll look at implementing this into the next FroydVillain release. My only reservation would be keeping a wee bit more space on /cache than 4MB since our OTA app uses it. We could always hack it to use a dir on /data I suppose.
Click to expand...
Click to collapse
Yea, that would be better.. The whole purpose of this thread is to make things more compatible, means same cmdline Also you wll need to write the instructions for the recovery to /dev/cache then, keep that in mind
I will also add the RecoveryMod and an explanation in the documentation now.

I think the limitation of needing to switch recovery when changing ROMs is quite bothersome. Is there anyway we can get a recovery which supports both modes?

erasmux said:
I think the limitation of needing to switch recovery when changing ROMs is quite bothersome. Is there anyway we can get a recovery which supports both modes?
Click to expand...
Click to collapse
Sure, it can be done, but that would take a looot of work!

maxisma said:
Sure, it can be done, but that would take a looot of work!
Click to expand...
Click to collapse
More than I think it would be worth, to be honest. It'd make more sense for all the ROM developers to pull together on this and just make it a fact that we're giving more space to data, since it also eliminates the need to create fancy hacks moving dalvik to cache or to sdcard or splitting it between 2-3 file systems to cater for people who like to have the entire Android Market on their phone.
This has my/Villain's full support Maxisma, it makes perfect sense. Might I suggest you PM the other ROM developers here, or at least the popular ones like Fusion etc, and refer them to this thread so we can all work together on it.
Now that it's safe to assume that HTC have pretty much ditched the Hero, it makes sense for us to fix/improve -everything- including partition layout. There is a lot of wasted space in /cache that only gets used if a ROM developer starts fudging about with where dalvik lives, but /cache isn't quite big enough to completely migrate dalvik cache to for people who like to have a lot of apps.

Is there any more work on this? :d

shinyfong said:
Is there any more work on this? :d
Click to expand...
Click to collapse
I believe maxisma stopped work on it due to it breaking something or causing something not to work. I think he mentioned it in his Rom thread...

pulser_g2 said:
I believe maxisma stopped work on it due to it breaking something or causing something not to work. I think he mentioned it in his Rom thread...
Click to expand...
Click to collapse
It was me who broke it ;-) I accdidentally booted with a different mtd layout and thus killed all my data.
This method is perfectly fine though.
But I switched to a Nexus and I don't have a Hero anymore.

[ROM]JPM/JP6 "GoodBye RFS" ROM 0.2 (pre rooted, pre lagfixed, extremely experimental)

[ROM]JPM/JP6 "GoodBye RFS" ROM 0.2 (pre rooted, pre lagfixed, extremely experimental)
This is an ultimately experimental ROM. It might break your phone, cause headaches and data loss. This is only a showcase on how a ROM (mostly) without RFS(*) would work.
(*): this is only marketing bull****. The /efs partition still uses rfs in this rom.
This ROM contains knowledge from ChainFire, newmail, RyanZA, supercurio, ykk_five, ziggy (and me). Many thanks to them.
For the people who only care about scores and such:
Quadrant: 2006
Linpack: 14.501
Result of mount command:
Code:
/dev/block/stl9 on /system type [B]ext2 [/B](ro,noatime,nodiratime,errors=continue)
/dev/block/loop2 on /data type [B]ext2 [/B](rw,noatime,nodiratime,errors=continue)
/dev/block/loop1 on /dbdata type [B]ext2 [/B](rw,noatime,nodiratime,errors=continue)
/dev/block/stl11 on /cache type [B]ext2 [/B](rw,noatime,nodiratime,errors=continue)
For the people who actually care:
What is this?
This is a highly expermiental all-in-one lagfixed and rooted ROM based on JPM and JP6.
How to install?
You don't want to install this. Seriously... But you can find the DL link somewhere in this post if you're still curious. Simply open up Odin, use the contained pit, CSC, MODEM and PDA files, check re-partition, and wait.
It hangs after flashing at the initial boot screen (this was for version 0.1. Version 0.2 should boot up faster)
Yep, because it generates a 1.5GB large file, this takes around 3-4 minutes. It might also crash (shutdown, or switch to the battery loading screen) during this time, in case you have to reboot and try again. (or switch to a rom that's not experimental)
Hey, do I have to wait every boot? (this was for version 0.1. Version 0.2 should boot up faster)
Nope, only the first and second boot, and after each factory reset. (between the first and second boot there is a factory reset because of the CSC being applied by the recovery module)
Is this rom safe?
No. Moving near a melted nuclear reactor is safer than this.
Hey, this doesn't work / All my data is wiped / etc.
You've been warned.
For the technical people:
How?
Factoryfs.rfs was converted to ext2 on the phone prior flashing, and during flashing you actually flash "/system" as ext2 instead of rfs. Dbdata is empty, and will be replaced on the first boot, and cache.rfs was also converted to ext2 (so the csc files can be loaded on first boot), but will be actually reformatted on first boot. A pre-init script takes care of the cleaning up, and creating of ext2 partitions. The /data and /dbdata partitions are actually "dual-ext2'd" so they reside in a loop device which resides in an ext2 partition. The rationale behind this is to delay the fsync's which is the major cause of the lag. I also tried to do an "only ext2 without loop device" version, but that was useless (I've even got quadrant scores below 1k(!) with it). /cache is only single ext2'd however for recovery functions to work.
Everything is done by the /sbin/fs-patch.sh script. Feel free to check it. The script logs into the /res directory, you can check whether there were any problems during mount there (if you could actually boot of course...)
Why ext2?
The ext4 module compiled from the official sources do compile, do load, mkfs.ext4 does create the partition, but when mounting the phone drops a kernel panic. Until I can find an ext4 (or ext3) module that actually works there will be ext2 used, just to demonstrate that a no-rfs solution is actually working.
Why JPM/JP6?
You can find the rationale on the multinational ROM topic. This rom is actually the lagfixed version of that rom without the extras.
DL link:
0.1: http://android.sztupy.hu/dl/SztupY_JPM_JP6_NORFS_ROM_0.1.zip (on my server. Might be slow)
0.2: http://android.sztupy.hu/dl/SztupY_JPM_JP6_NORFS_ROM_0.2.zip (on my server. Might be slow)
Differences between 0.1 and 0.2:
0.1 uses rfs on the device + ext2 on a loop
0.2 uses ext2 on both the device and on the loop. 0.2 also has a much-much faster loop file creator utility (that creates the 1.8GB file in a second), so booting times should be normal again.
0.2 has higher quadrant scores (breaks the 2k barrier), but 0.1 felt more responsive (at least for me). I don't know anything about battery usage and such.
0.2 has problems with apps from the market, that install themselves on the sdcard. Hotfix
Links:
- scripts from initramfs

Appreciate you can post more comments about the problems and performance of this experimental ROM
Thanks for the great work!
Sent from my GT-I9000 using XDA App

this is exciting

Just threw this on my Captivate(since firmwares are semi-compatible), waiting for the ext2 partition to get created, and will report back. This is pretty awesome though, good work!

Thank you, looks very-very-very cool! Flashing now.

Great work.
Sent from my GT-I9000 using XDA App

Excellent work! Can you make a version that makes the /data partition native ext2 instead of a loop device? Thanks!

Woah, great stuff, though I'm not gonna try it, sounds to dangerous. I've been using your other ROM and lovin' it, thanks!

Hey sztupy, good work man... cant wait to see the first reports...

Linpack: 14035
What?!?

anyone has any success loading this rom? i was being curious, i tried flashing on my phone, but kept restarting and looping at the initial Galaxy S GT-i9000 screen.
by the way the linpack score, is it 14035 or its just missing a decimal point? lol!

giantdroid said:
anyone has any success loading this rom? i was being curious, i tried flashing on my phone, but kept restarting and looping at the initial Galaxy S GT-i9000 screen.
by the way the linpack score, is it 14035 or its just missing a decimal point? lol!
Click to expand...
Click to collapse
Try to reflash it using Odin. That's what I did and it's running now
I'm getting 14.211 mflops in 5.9 secs

What languages are in swype ?
Does it contain romanian ?

how is the stability so far, for you that have tested it? and screw the scores. How is the feeling? any lagg? anything?

Nice one! Has anybody had any issues with /system being EXT yet? I'm guessing not, but this is going straight on my phone anyway!
EDIT: noatime,nodiratime performs a lot better than relatime btw
Why is /data on loopback on top of RFS? Seems silly!
You should have done /data as a loopback on top of /dbdata EXT2 for extreme speed! Do it!

Just installed this ROM/Kernel...
Setup and Flashing went without any hitch. The first boot was longer than usual, but as it was forewarned..so no surprises there.
I will give it a thorough test today and post the issues here, if any.
Thank you for this amazing work.

lealdud1 said:
how is the stability so far, for you that have tested it? and screw the scores. How is the feeling? any lagg? anything?
Click to expand...
Click to collapse
No Lag at at all. This is by far the ZIPPIEST ROM I have tried...(without any lag-fix installed)
I agree, screw the scores...it's the feel and the response that matters and this ROM is just great at it.
Haven't used it much but no FC or any other errors...so far, so good.

RyanZA said:
Nice one! Has anybody had any issues with /system being EXT yet? I'm guessing not, but this is going straight on my phone anyway!
EDIT: noatime,nodiratime performs a lot better than relatime btw
Why is /data on loopback on top of RFS? Seems silly!
You should have done /data as a loopback on top of /dbdata EXT2 for extreme speed! Do it!
Click to expand...
Click to collapse
I'll definatly give this rom a try when this ^ has been done and when a few more ppl have tested it without to many issues.
Thanks in advance for all your work on this rom guys, I love your other rom sztupy.

Sounds very exciting! Will probably wait until you manage to get /data as ext2 to give it a try. Still, well done with this!

will try on saturday...just to see if any further "improvement" will crop up by then
thank you sztupy for putting this out here!

My Galaxy Nexus is being very laggy...

I bought my phone about a week ago, and I noticed it was pretty slow after installing some apps, even slower than my previous Nexus S.
I changed my phone from yakjuxw to yakju yesterday, and updated to 4.2. I even did a factory reset after everything was done.
It was the same, it started pretty fast but as I ran the apps from the backup I had made the phone started to slow down.
I still haven't managed to find which app is causing me problems, so I was hoping someone here could help...

Did you use Titantium Backup for apps?
As far as I know, it is recommended not to restore all apps via Titantium Backup but only the ones that have some data associated to them like games with their saves. So try installing a fresh 4.2 ROM, only restore the apps that needs their data, and download the others via Play Store
I hope you can either avoid the lag this way or at least spot the app causing it

ahmadallica said:
Did you use Titantium Backup for apps?
As far as I know, it is recommended not to restore all apps via Titantium Backup but only the ones that have some data associated to them like games with their saves. So try installing a fresh 4.2 ROM, only restore the apps that needs their data, and download the others via Play Store
I hope you can either avoid the lag this way or at least spot the app causing it
Click to expand...
Click to collapse
No, I restored it through the Nexus Toolkit (the GUI version).
I only restored normal apps and none of the system apps or data. And this has been on absolutely stock Google ROMs ever since I bought the phone.

KaiZ51 said:
I bought my phone about a week ago, and I noticed it was pretty slow after installing some apps, even slower than my previous Nexus S.
I changed my phone from yakjuxw to yakju yesterday, and updated to 4.2. I even did a factory reset after everything was done.
It was the same, it started pretty fast but as I ran the apps from the backup I had made the phone started to slow down.
I still haven't managed to find which app is causing me problems, so I was hoping someone here could help...
Click to expand...
Click to collapse
That happens when you restore rom essential apps...you only need to restore the apps you downloaded.
Sent from my Galaxy Nexus using xda premium

Maybe you have the eMMC bug/issue which may occur if your phone was produced 08/2012.
To check this install the "eMMC Brickbug Check" tool and verify if your if chip type is V3U00M and date 08/2012.
https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
If yes check this link for a workaround for this annoying bug:
http://forum.xda-developers.com/showpost.php?p=35020486&postcount=10

KaiZ51 said:
No, I restored it through the Nexus Toolkit (the GUI version).
I only restored normal apps and none of the system apps or data. And this has been on absolutely stock Google ROMs ever since I bought the phone.
Click to expand...
Click to collapse
try to flash the image again and dont restore this time... see if that fixes your issue

navien said:
Maybe you have the eMMC bug/issue which may occur if your phone was produced 08/2012.
To check this install the "eMMC Brickbug Check" tool and verify if your if chip type is V3U00M and date 08/2012.
https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
If yes check this link for a workaround for this annoying bug:
http://forum.xda-developers.com/showpost.php?p=35020486&postcount=10
Click to expand...
Click to collapse
Well, I've just checked it, and it seems like my phone falls within the parameters for this bug... The only difference is the date is 09/2012. But is there a way to know for sure that I'm affected by this bug? Besides, I'm going to have to root the phone, which is going to be a bit annoying since I really didn't want to do it because I may have problems with the warranty in case I need to return it...
Also, if I flash a custom ROM in the future, will I have to do that again, or do custom ROMs usually come with that fix?
k786 said:
try to flash the image again and dont restore this time... see if that fixes your issue
Click to expand...
Click to collapse
I was thinking of trying that as well, though it may be annoying because I'll lose my data... But if I have to I guess I really don't have a choice...

KaiZ51 said:
I was thinking of trying that as well, though it may be annoying because I'll lose my data... But if I have to I guess I really don't have a choice...
Click to expand...
Click to collapse
delete the userdata from the image and it wont wipe your internal storage

KaiZ51 said:
Well, I've just checked it, and it seems like my phone falls within the parameters for this bug... The only difference is the date is 09/2012. But is there a way to know for sure that I'm affected by this bug? Besides, I'm going to have to root the phone, which is going to be a bit annoying since I really didn't want to do it because I may have problems with the warranty in case I need to return it...
Also, if I flash a custom ROM in the future, will I have to do that again, or do custom ROMs usually come with that fix?
Click to expand...
Click to collapse
All people reported this bug (at least what i´ve found) have production date of 08/2012 - maybe this bug also affects newer models.
I think if your chip type is V3U00M then your'e phone is affected. But your can test this easily. Just copy a huge file (i've copied 1 hd movie ~11GB) to the internal storage. The phone should slow down extremely, even if you delete the file again. For example: my phone needed 4-6 seconds to open the contacts app - sometimes even more.
Rooting is no big issue - you can easily revert to stock image.
If you flash a ROM you will to have implement the workaround again. Custom ROMs will not include this fix in general because if you remount the data partition with the discard option on an eMMC other than V3U00M your phone will be hard bricked.

navien said:
All people reported this bug (at least what i´ve found) have production date of 08/2012 - maybe this bug also affects newer models.
I think if your chip type is V3U00M then your'e phone is affected. But your can test this easily. Just copy a huge file (i've copied 1 hd movie ~11GB) to the internal storage. The phone should slow down extremely, even if you delete the file again. For example: my phone needed 4-6 seconds to open the contacts app - sometimes even more.
Rooting is no big issue - you can easily revert to stock image.
If you flash a ROM you will to have implement the workaround again. Custom ROMs will not include this fix in general because if you remount the data partition with the discard option on an eMMC other than V3U00M your phone will be hard bricked.
Click to expand...
Click to collapse
So, I went ahead and followed the instructions on the link you gave me... And it seems to be much better so far I still haven't tested enough, but I think the problem is pretty much fixed. I just have a few more questions if you don't mind...
1- When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
2- Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
3- Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?

KaiZ51 said:
So, I went ahead and followed the instructions on the link you gave me... And it seems to be much better so far I still haven't tested enough, but I think the problem is pretty much fixed. I just have a few more questions if you don't mind...
1- When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
2- Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
3- Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?
Click to expand...
Click to collapse
Bumping...

KaiZ51 said:
So, I went ahead and followed the instructions on the link you gave me... And it seems to be much better so far I still haven't tested enough, but I think the problem is pretty much fixed. I just have a few more questions if you don't mind...
1- When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
2- Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
3- Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?
Click to expand...
Click to collapse
The dd command fills the entire partition till full, therefore the not enough space message is normal.
I´ve not tested how to implemt this fix in a ROM before flashing.
In theory you only need to add the file with the script into the init.d folder of the zip before flashing.
I´ve made IO Benchmarks with AndroBench to check if the script works:
with enabled script i get for example RND WR ~135 IOPS without script 54 IOPS.

navien said:
The dd command fills the entire partition till full, therefore the not enough space message is normal.
I´ve not tested how to implemt this fix in a ROM before flashing.
In theory you only need to add the file with the script into the init.d folder of the zip before flashing.
I´ve made IO Benchmarks with AndroBench to check if the script works:
with enabled script i get for example RND WR ~135 IOPS without script 54 IOPS.
Click to expand...
Click to collapse
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Sorry about all the trouble with this problem, it's just as you probably know the phone is barely usable with this bug so I have no choice but to ask for help... Google should really fix this in an update, it's something pretty urgent in my opinion.

KaiZ51 said:
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Sorry about all the trouble with this problem, it's just as you probably know the phone is barely usable with this bug so I have no choice but to ask for help... Google should really fix this in an update, it's something pretty urgent in my opinion.
Click to expand...
Click to collapse
Oh, and do you think I should go to the store to replace my phone? I still haven't understood if this is a software or hardware issue, but I'm believing it's the first...

KaiZ51 said:
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Sorry about all the trouble with this problem, it's just as you probably know the phone is barely usable with this bug so I have no choice but to ask for help... Google should really fix this in an update, it's something pretty urgent in my opinion.
Click to expand...
Click to collapse
OK. The workaround with the script needs a ROM with init.d support. I thought this was mentioned in the linked thread.
I´m using THIS one.
The real fix is the re-mounting of the /data & /cache partitions using the discard option. If you type the command in a terminal window it fixes the problem temporary.
After reboot the problem is back. So you need to make a init.d script which will be executed every boot.
I think the dd command 'cleans' the free memory but i'm not sure.
To my opinion it doesn't make any sense to replace the phone because there's a big chance to get a new one with same problem.
So it is a software bug which should be solved by google.

navien said:
OK. The workaround with the script needs a ROM with init.d support. I thought this was mentioned in the linked thread.
I´m using THIS one.
The real fix is the re-mounting of the /data & /cache partitions using the discard option. If you type the command in a terminal window it fixes the problem temporary.
After reboot the problem is back. So you need to make a init.d script which will be executed every boot.
I think the dd command 'cleans' the free memory but i'm not sure.
To my opinion it doesn't make any sense to replace the phone because there's a big chance to get a new one with same problem.
So it is a software bug which should be solved by google.
Click to expand...
Click to collapse
Hmm I see... But from what I understood, you can make the script run at boot with apps like ROM Toolbox and Script Manager, correct? Although I'm not sure if it's running on my system, I've tried both apps and the benchmarks are always in the 30's...
Or do you really need a ROM with init.d support? Also I have BusyBox installed on Google's stock ROM, not sure if that is enough to able to run init.d scripts.
But how would you run scripts with init.d? Sorry, I'm a noob to this kind of stuff, I never did stuff like this...

KaiZ51 said:
Well, I've just checked it, and it seems like my phone falls within the parameters for this bug... The only difference is the date is 09/2012.
Click to expand...
Click to collapse
Thank you for confirming chips produced 09/2012 as bad. Added this to the post linked above.
KaiZ51 said:
When I ran the dd command, it took a while like the instructions said, but when it finished it said something about not enough space. Could something have gone wrong, or is this normal?
Click to expand...
Click to collapse
This is normal as we don't give the dd command a particular file size to create. So it simply writes data until no space is left.
KaiZ51 said:
Since it isn't likely custom ROMs implement this fix, is there any way I can "stick" this fix on the phone's system so that I don't have to worry about setting it every time I flash a new ROM?
Click to expand...
Click to collapse
If you are only using ROMs that support something like init.d inside data (like CM), next time to worry about this will be when you do a full wipe.
Probably then the problem will already be fixed by Google or others as it gains more attention over time.
KaiZ51 said:
Is there any way to make sure that the script I set up in Script Manager is fully working and running on boot?
Click to expand...
Click to collapse
Jup. Type 'mount' in Terminal or adb after you rebooted your phone:
# mount
[...]
/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data ext4 rw,noatime,errors=panic,barrier=1,nomblk_io_submit,data=ordered,noauto_da_alloc,discard 0 0
[...]
Click to expand...
Click to collapse
=> discard option added, script ran successfully
KaiZ51 said:
Apparently it isn't running, since I get my Random Write score in the 30's IOPS. Besides that, I made Script Manager output logs, and it seems like it says it could not mount.
Click to expand...
Click to collapse
Maybe you have to check something like 'run as root' or similar in Script Manager.
KaiZ51 said:
So what can I do? I'm not sure if I've already said this, but I'm on the stock 4.2.1 yakju ROM, if it matters. I could do this the init.d way, but I'm not sure if it works fine on stock ROM...
Click to expand...
Click to collapse
Nope. Stock does not support init.d.
KaiZ51 said:
Also, something I haven't yet understood, is the dd command for checking if the fix works temporarily, or do you really need to do it in order to prepare the phone for the script?
Click to expand...
Click to collapse
You can use the script without. The phone will speed up over time as more and more data is written/deleted and therefore the eMMC chip gets some discard commands.
The dd + rm just speeds up the process as all free blocks will be told to the eMMC chip due to the discard option added beforehand.
Another possibility (after installing the script and confirming that it works) would be to copy a large file that fills almost all space on the phone and remove it afterwards. The dd command is just considerably faster.
KaiZ51 said:
And do you need to have as much empty space as possible before running the command, or you don't need to care about that?
Click to expand...
Click to collapse
You don't need to care. Just keep around 1,0-1,5 GiB of free space everytime: Benchmark
KaiZ51 said:
Oh, and do you think I should go to the store to replace my phone? I still haven't understood if this is a software or hardware issue, but I'm believing it's the first...
Click to expand...
Click to collapse
Well, you might get a replacement phone and through bringing it back the chance that Google gets aware of the problem may be higher.
But possibly they will only wipe all data which makes the phone fast again for some time and tell you there is nothing wrong with it...
You may even think about it from this point of view: If the fix works for you, you have a phone with a blazingly fast eMMC chip, faster than any GNex produced before 08/2012 (until you have less than 1 GiB of free space on /data)
KaiZ51 said:
Google should really fix this in an update, it's something pretty urgent in my opinion.
Click to expand...
Click to collapse
+1

ph4zrd said:
Thank you for confirming chips produced 09/2012 as bad. Added this to the post linked above.
This is normal as we don't give the dd command a particular file size to create. So it simply writes data until no space is left.
If you are only using ROMs that support something like init.d inside data (like CM), next time to worry about this will be when you do a full wipe.
Probably then the problem will already be fixed by Google or others as it gains more attention over time.
Jup. Type 'mount' in Terminal or adb after you rebooted your phone:
=> discard option added, script ran successfully
Maybe you have to check something like 'run as root' or similar in Script Manager.
Nope. Stock does not support init.d.
You can use the script without. The phone will speed up over time as more and more data is written/deleted and therefore the eMMC chip gets some discard commands.
The dd + rm just speeds up the process as all free blocks will be told to the eMMC chip due to the discard option added beforehand.
Another possibility (after installing the script and confirming that it works) would be to copy a large file that fills almost all space on the phone and remove it afterwards. The dd command is just considerably faster.
You don't need to care. Just keep around 1,0-1,5 GiB of free space everytime: Benchmark
Well, you might get a replacement phone and through bringing it back the chance that Google gets aware of the problem may be higher.
But possibly they will only wipe all data which makes the phone fast again for some time and tell you there is nothing wrong with it...
You may even think about it from this point of view: If the fix works for you, you have a phone with a blazingly fast eMMC chip, faster than any GNex produced before 08/2012 (until you have less than 1 GiB of free space on /data)
+1
Click to expand...
Click to collapse
Thanks, that cleared a lot of questions.
So, after having tested the phone some more time (and I do have discard enabled at boot after all), the phone still seems pretty slow to me.
Yesterday I did the discard command with the adb shell, and then rebooted with the discard script enabled, but it's still pretty slow...
I've also benchmarked the phone in AndroBench a few times after this and Random Write scores ranged from as low as 6 (yes, six) IOPS, to 60's IOPS.
Still, this isn't that good since it seems like normal scores are in the 100's.
I really don't know what I should do now... Maybe the eMMC chip isn't actually the problem? But I find that rather strange since I don't think I have any apps that I already didn't have on my old Nexus S, and the phone does seem slower than my old one.

KaiZ51 said:
I really don't know what I should do now... Maybe the eMMC chip isn't actually the problem? But I find that rather strange since I don't think I have any apps that I already didn't have on my old Nexus S, and the phone does seem slower than my old one.
Click to expand...
Click to collapse
How much free space do you have left on /data or /sdcard?
And you used the dd-rm-combination after remounting with discard, right?

ph4zrd said:
How much free space do you have left on /data or /sdcard?
And you used the dd-rm-combination after remounting with discard, right?
Click to expand...
Click to collapse
I have 1.71GB free now.
And what do you mean about your second question? If you're asking if I used those commands when I connected the phone to my PC via USB Debugging, then yes.
If you're talking about the script that runs at boot, all I have in that script is
Code:
#!/system/bin/sh
mount -o remount,discard /data
mount -o remount,discard /cache
Should I put the script like this?
Code:
#!/system/bin/sh
mount -o remount,discard /data
mount -o remount,discard /cache
dd if=/dev/zero of=/data/tmp.bin
rm /data/tmp.bin
I didn't put them there since I thought the dd and rm commands were only meant to be run when connected via USB and not at boot as well...

[MOD] ext2 file system for /system - Feb. 17 UPDATED

In short, what I will be doing here is mounting the /system partition as file system EXT2. Default is EXT4. The reason for doing this is simple. The /system partition is more of an access database where information is read and never written. The goal here is to remove journaling and not only journaling but the redundancy of the code tree of EXT4 by simply killing the EXT4 journal and leaving it mounted and formatted as EXT4.
EXT4 – The file system uses a function called journaling. Journaling, in short, is a file system log. What this provides to you as the user is a quick method of recovery if there is ever a system failure: unclean shutdown, file corruption, etc. If there is ever a problem, the journal is called and the data is restored with no issues. The cost of this journaling feature, however, is CPU time/usage. CPU cycles are used to write the journal to the disk.
EXT2 – This file system does not use journal. No recovery method, etc. So if something is corrupted, there is no way to recover corrupted files/blocks/data.
What does all of this mean? – Simple. What it means is those of us who are rooted, running a stable ROM/Kernel combo, and using a backup method such as TWRP or CWM, can safely use EXT2 for /system without any worry because all we need to do is make a backup of our /system partition via recovery, tuck it away on our internal SD card and save it for a rainy day - restore it if there is every an unclean shutdown (battery pull, reboot caused by an unstable kernel, etc.).
What benefits will you see/feel?
Honestly, I have no idea at this point. I know for a fact that the device will boot faster and read operations on the /system partition will be absolutely insanely fast. As fast as they can possibly be on the Note 3. As far as “end of the day” battery savings, well, this is kind of the point of me doing this and sharing. I am going to find out, and post my results here so other people can decide if they do or don’t want to do this as well. If all goes well, I’ll edit this post tomorrow with some quick instruction on how to convert the file system. It should be a quick and easy process.
Other benefits of using EXT2 instead of EXT4:
EXT2 is backward compatible with EXT4. What this means is you can have a file system formatted to EXT2, and it can be mounted as EXT4 and it will only utilize the newer useful features found in EXT4 that were not originally present when EXT2 was introduced. When mounted as EXT4, EXT2 will not use journaling, but will use EXT4’s superior block allocation and “tagging” feature. EXT4 has the ability to mark unused blocks on the disk so it knows to not look there for data – this saves precious time in read operations. EXT2 does not have this feature… except when it is mounted as EXT4
The biggest advantage, here, is to get rid of that useless EXT4 journaling feature used on our RO /system and save CPU cycles. We use backups.We are a different breed of users, right? We demand performance and push our devices to the limits and somehow manage to maintain a stable and usable system, correct?
YES! So, we’re gonna go ahead and take advantage of this super awesome backward compatibility of EXT2 on the /system partition and get some positive performance index out of it
INSTRUCTIONS - convert /system to EXT2
1. Unzip the .zip folder of your ROM of choice.
2. Find /META-INF/com/google/android/updater script.
3. Open the updater-script file in a text editor.
Any lines where you see "EXT4" and "system" in the same line, you need to change that 4 to a 2. Only do this for lines with system and EXT4 in the same line.
4. Save the changes, then zip the ROM back up.
5. Place ROM on your internal SD card, then boot into recovery - YOU MUST BE USING TWRP FOR THIS
6. Once you get into recovery, you will see your TWRP options (there are 8 tiles in recovery) - select the one that says "Advanced"
7. You will now see 6 tiles. On the left side, select the one that says "Terminal Command"
8. At the top you should see a / symbol - this is the directory you are going to begin your session in. You want it to be /
9. On the bottom right of the screen, hit "Select"
This next part is very important. Do not mess up.
When you get to the terminal screen, type this command:
Code:
mke2fs /dev/block/mmcblk0p23
DO NOT continue until you have double checked that the number you punched in is 23! I cannot stress this enough. 23.... 23..... 23..... again that last part is "...mmcblk0p23"
After you have verified the correct partition number 23, hit the GO button on the keyboard to execute the command. It will run for a couple seconds and finish up.
After it finishes reformatting, flash your ROM of choice (the one where you edited any lines). When you are done, boot up.
You are now running an EXT2 file system for your /system partition. Welcome to the thunder dome

Cool, can't wait to try, thanks for this finding
Sent from my SM-N900T using Tapatalk

Why not just create and mount an ext4 filesystem with no journal? There is a reason they made the ext4 driver able to mount ext2,3 filesystems. Aside from journaling, which can be disabled, ext4 and it's driver are generally better.
edit - Didn't mean to quote.

muqali said:
Why not just create and mount an ext4 filesystem with no journal? There is a reason they made the ext4 driver able to mount ext2,3 filesystems. Aside from journaling, which can be disabled, ext4 and it's driver are generally better.
edit - Didn't mean to quote.
Click to expand...
Click to collapse
The reason is because the op paths in the file system tree (speaking of EXT4) are optimized for the journal. Without the journal the code path is redundant and the journal-optimized block has empty overhead. EXT2's strength is it's simplicity in structure.
Basically what this translates to is EXT4 formatted disk, mounted as EXT4 and with no journal, is not as fast or efficient as EXT2 formatted disk mounted as EXT4.
I am running this set up right now. This thread will be updated soon with instruction on how to convert it.

Ext4 has quicker read times than Ext2 which too me is going to the biggest perofmance increase.

This sounds interesting, but I think I'll wait to see others' experiences before giving it a go myself. Will be keeping an eye on this thread though.
Sent from my SM-N9005 using XDA Premium 4 mobile app

The only reason EXT4 has faster read times is because of what I just explained - ext4 uses a method of marking unused blocks on a disk, so it doesn't scan them looking for something. EXT2 does not have this feature. However, when an EXT2 formatted disk is mounted as EXT4, it does utilize this feature of EXT4.

Do you have any data, your own or third party to back this up? Do you plan on using an ext2 system with the ext4 driver? Or the old ext2 fs driver? As I understand it, the ext4 driver was given the ability to mount 2/3 filesystems for simplicity sake as well as the newer driver being better but I could be mistaken.
edit - The way you explained it in your last post seems to sound like you'll use ext4 driver on an ext2 fs, I was just asking because I wasn't 100% sure.

muqali said:
Do you have any data, your own or third party to back this up? Do you plan on using an ext2 system with the ext4 driver? Or the old ext2 fs driver? As I understand it, the ext4 driver was given the ability to mount 2/3 filesystems for simplicity sake as well as the newer driver being better but I could be mistaken.
edit - The way you explained it in your last post seems to sound like you'll use ext4 driver on an ext2 fs, I was just asking because I wasn't 100% sure.
Click to expand...
Click to collapse
That was the intention, correct. Using EXT2 formatted /system but mount it as EXT4 - for the reasons I outlined. To effectively remove journaling and not only that, but the redundant overhead of journaling in the fs tree which would still remain if I were to, say, run this command...
Code:
tune2fs -O ^has_journal /dev/block/mmcblk0p23
EDIT** and so far, yes the difference has been noticeable in boot up time - which is a clear indicator of a performance increase. It loads the /system much faster during boot. Battery life has been slightly better as well.

Do you have a video or benchmark showing the differnce?

LancerV said:
Do you have a video or benchmark showing the differnce?
Click to expand...
Click to collapse
A benchmark? People actually use those? lol.
My own device before doing this mod booted in about 21 seconds from the off position. After doing this it was 15 seconds. I full booted it 3 times for each EXT4 and EXT2... it was consistently the same.
You don't need a benchmark to understand there is an obvious performance increase there. Battery life has also been a little better today. My usage on a daily basis is consistently the same with no changing variables. 15 hours off the charger and 75% battery with 1 hour and 30 minutes screen on time is what I typically see. Today I was 15 hours off the charger, 81% battery with 1 hour and 30 minutes screen on time.
CPU cycles have been reduced, obviously.
If you wanna give it a go... You won't regret it. Post your results here so we can compare :highfive:

Nothing wrong with storage benchmarks, hell the best Windows/Linux/Unix storage benchmark is from 2006 and works perfectly. It's pretty much a staple when it comes to setting up Fibre, and 10Gbe SAN's to make sure the throughput you should be getting you are getting and to test various raids in their IO performance along with read/write performance.
So to say lol people still use benchmarks is pretty naive.

LancerV said:
Nothing wrong with storage benchmarks, hell the best Windows/Linux/Unix storage benchmark is from 2006 and works perfectly. It's pretty much a staple when it comes to setting up Fibre, and 10Gbe SAN's to make sure the throughput you should be getting you are getting and to test various raids in their IO performance along with read/write performance.
So to say lol people still use benchmarks is pretty naive.
Click to expand...
Click to collapse
I have not seen one benchmark available on the playstore that is even remotely relevant. What a joke it is to see a tech article running a quadrant test comparing two devices using a benchmark... so, if you were talking about one of those - quadrant, antutu, etc... none of these are going to give me an accurate representation of what kind of performance increase or decrease I am seeing for /system because they don't test those partitions. There are more accurate ways to run a performance test on a disk.... but it's quicker for me to just go ahead and reboot the device since, well, I know what I am doing and happen to be doing it on a portion of the disk where a majority of the work by the CPU is coming from accessing this particular partition of the device.
During boot, there is one task being executed and one task only... booting! Any most everything being loaded is coming from where? /system
Naive? I spent time on Google's team as a software engineer a couple years back... I am far from naive. You are just not looking at this from a practical or logical point of view.
I'll give you an analogy before I go to bed so you can better understand:
If your car runs out of gas, and stops running, and somebody gives you a ride home, then somebody else calls you and says "Hey, I just saw your car on the side of the road, saw your post on G+ about running out of gas. Well, I happened to have a gas can with me and put a gallon of gas in it for you. Go pick it up!"
Now you get a lift back to your car, put the key in, and it starts right up. Do you then turn it off and walk to a gas station, get a gas can, walk back, put more gas in it, and drive away? No, you don't. Because you have already obtained a positive result. There is no need for "testing" at that point. You have clearly established a positive result.
Anyways, benchmarks.... can be useful sometimes. But you are mistaken if you think:
A) They will give me anymore information than I know at this point regarding the test method...
B) I am going to be allocating more time and resources to run a "relevant" test on my /system partition
C) I have not already obtained a clear result
Not trying to sound arrogant... but I've been doing this a while. I'll pass on the benchmarking this time around.

cun7 said:
I have not seen one benchmark available on the playstore that is even remotely relevant. What a joke it is to see a tech article running a quadrant test comparing two devices using a benchmark... so, if you were talking about one of those - quadrant, antutu, etc... none of these are going to give me an accurate representation of what kind of performance increase or decrease I am seeing for /system because they don't test those partitions. There are more accurate ways to run a performance test on a disk.... but it's quicker for me to just go ahead and reboot the device since, well, I know what I am doing and happen to be doing it on a portion of the disk where a majority of the work by the CPU is coming from accessing this particular partition of the device.
During boot, there is one task being executed and one task only... booting! Any most everything being loaded is coming from where? /system
Naive? I spent time on Google's team as a software engineer a couple years back... I am far from naive. You are just not looking at this from a practical or logical point of view.
I'll give you an analogy before I go to bed so you can better understand:
If your car runs out of gas, and stops running, and somebody gives you a ride home, then somebody else calls you and says "Hey, I just saw your car on the side of the road, saw your post on G+ about running out of gas. Well, I happened to have a gas can with me and put a gallon of gas in it for you. Go pick it up!"
Now you get a lift back to your car, put the key in, and it starts right up. Do you then turn it off and walk to a gas station, get a gas can, walk back, put more gas in it, and drive away? No, you don't. Because you have already obtained a positive result. There is no need for "testing" at that point. You have clearly established a positive result.
Anyways, benchmarks.... can be useful sometimes. But you are mistaken if you think:
A) They will give me anymore information than I know at this point regarding the test method...
B) Allocating the time and resources to run a relevant test on my /system partition
C) I have not already obtained a clear result
Not trying to sound arrogant... but I've been doing this a while. I'll pass on the benchmarking this time around.
Click to expand...
Click to collapse
Right on. Great work OP. While EXT2 isnt for everyone. Experienced users can gsin value from using it. Nice Work!!!
Sent from my Samsung Galaxy Note 3 using JellyBombed Tapatalk.

My phone takes about 15secs to boot up not sure Im going to really notice a 1-2sec diffrence, a better analogy would be taking a car that does 0-60 in 6secs and a pos looking car and one that does 0-60 in 6.2 secs and be looking like a sports car. The differnce would be so minuscial that if you asked people which one accelerated faster they would naturally pick the one that looks like a sports car because thats how peoples minds are trained to think sportty looking car = quicker.
Its kinda a mental placebo effect, hence why I asking if you had a boot up video seems like that would be proof enough.
Also ran a top command and suprise system is using 1% and its the top command so I dont see where you are coming up with the extreme cpu cycles you say journaling is causing. Not to mention the fact /system is pretty much only called upon boot. Most other times its going to be pulling r/w cycles from /data or /sdcard.

LancerV said:
My phone takes about 15secs to boot up not sure Im going to really notice a 1-2sec diffrence, a better analogy would be taking a car that does 0-60 in 6secs and a pos looking car and one that does 0-60 in 6.2 secs and be looking like a sports car. The differnce would be so minuscial that if you asked people which one accelerated faster they would naturally pick the one that looks like a sports car because thats how peoples minds are trained to think sportty looking car = quicker.
Its kinda a mental placebo effect, hence why I asking if you had a boot up video seems like that would be proof enough.
Also ran a top command and suprise system is using 1% and its the top command so I dont see where you are coming up with the extreme cpu cycles you say journaling is causing. Not to mention the fact /system is pretty much only called upon boot. Most other times its going to be pulling r/w cycles from /data or /sdcard.
Click to expand...
Click to collapse
The placebo effect you are speaking of are typically people that don't know what they are doing, and are simply just excited about something.
An example of this would be the 9 out of every 10 posts I see in a ROM thread over the years talking about how much smoother their device is after flashing "xxxxx ROM"... a stop watch is a pretty reliable method for checking boot times, which is what I used for this particular scenario because I knew it would be relevant. Also the fact that my usage is pretty much exactly the same every day is a pretty solid test attribute. Any change in battery life at 15 hours... even if it is 1%... I notice it.
Also, my own personal ROM that I use is entirely odexed. So, nothing is being drawn from /data/dalvik-cache that is a /system/framework or /system/app function. It is noticeably more efficient because the 280+ .odex files are being read from the same location... which is now ext2, and not ext4.
Is this kind of starting to make sense now or am I losing you more?

I am not aware of all the file systems on linux. What happens to the partition if you restore a nandroid backup of the system partition that was converted to ext2 but the backup was ext4? And/or if backup was ext2? Just curious.
Sent from my SM-N900T using Tapatalk

Compusmurf said:
I am not aware of all the file systems on linux. What happens to the partition if you restore a nandroid backup of the system partition that was converted to ext2 but the backup was ext4? And/or if backup was ext2? Just curious.
Sent from my SM-N900T using Tapatalk
Click to expand...
Click to collapse
It will write the data to the disk as it should. You can do this without having any issues.
I've never tried restoring an EXT2 backup to an EXT4 formatted disk... So I have no answer for you there. It all kind of depends on exactly how TWRP's backups are created... I think they use .tars ... I'm not sure

Would this by any chance work on an AOSP/CM/AOKP ROM? I've tried using it with CM and LiquidSmooth but it stops every time after "erasing system" with "script aborted (no error message)".
Nevermind, I found out the issue. I went back into the updater-script and removed this line: "format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");". It flashed perfectly after that (Liquid Smooth AOSP ROM).
Edit: Had an issue with the ROM not booting at first, it hung on the splash screen. What I did was reboot into TWRP, wiped cache and dalvik cache, went into terminal (in advanced) and typed this command: "setenforce 0". After that, type "getenforce" and make sure SELinux is set to Permissive. I'm not sure if the SELinux command helped at all but I did it just in case.

Hypercore said:
Would this by any chance work on an AOSP/CM/AOKP ROM? I've tried using it with CM and LiquidSmooth but it stops every time after "erasing system" with "script aborted (no error message)".
Nevermind, I found out the issue. I went back into the updater-script and removed this line: "format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");". It flashed perfectly after that (Liquid Smooth AOSP ROM).
Edit: Had an issue with the ROM not booting at first, it hung on the splash screen. What I did was reboot into TWRP, wiped cache and dalvik cache, went into terminal (in advanced) and typed this command: "setenforce 0". After that, type "getenforce" and make sure SELinux is set to Permissive. I'm not sure if the SELinux command helped at all but I did it just in case.
Click to expand...
Click to collapse
Code:
"format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");"
Change that 4 to a 2...
Code:
"format("[COLOR="Red"]ext2[/COLOR]", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");"