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.

Some possible insight on the cause of the RFS lag and work-around

Since I installed JPK on a test phone after claims that the RFS related lag has been fixed.. well.. I'd like to share my impressions:
- I have installed approx 100 apps after the flash (flashed / wiped / factory reset btw)
A this point, the phone while slightly slower than one with Voodoo is pretty fast
A few days later, it's still good enough.
- 5 days later, lag starts to be felt, and it's stronger every next day until it becomes annoying to use
That's exactly the same experience as I had on various Eclair roms without any lag-fix. I also had this on JP3 (early Froyo).
So yeah. I looked into the /init binary from samsung and it's supposed to make some file system checks from time to time when you restart the phone, but it does not appear to really carry on with that.
So I ran the checks myself:
- you need a rooted phone, and adb or a terminal
- find all RFS partitions:
$ su
# mount|grep -i rfs
- kill all processes, go flight mode and remount them read-only
$ su (if you're not root.. not going to repeat it again for subsequent commands)
# kill -9 <pid> of anything that use the patrition
# mount -oremount,ro /dev/block/....
- check the RFS filesystem and correct errors
# /system/bin/fsck_msdos -p -f /dev/block/....
Surprise, a million of RFS errors fixed such as:
/path/to/file starts with free cluster FIXED
Cluster XXX continues with cluster XXX in FAT 0 but is marked free in FAT 1 FIXED
Detected cluster chain loop head XXXX for p XXXX FIXED
FSNext block XXX is correct NumClusters XXX FIXED (weird one)
No LOST.DIR FIXED
Lost cluster chain at cluster XXX YY clusters lost FIXED (prolly lost files/data here!)
Repeat for each partition
reboot the phone at the end
SURPRISE! It doesn't lag much anymore.
Use the phone an hour, do the check again and you will see it's already full of errors.
Conclusion:
RFS is bugged (we knew that didn't we) but it looks like it's fixable, if ever Samsung figures out what is corrupting the file system exactly (it's closed source so we can't really find out easily)
It might be possible to figure it out by looking at VFAT sources too.
I would be very interested to see if that fixes the lag for everyone or if i'm an isolated case and all my RFS partitions are on bad hardware or if it's really software corruption as I am guessing
Small disclaimer:
im not responsible for any data loss etc. no warranties etc. fixing file system even readonly might cause data loss due to the bugs in RFS. you've been warned lol.

My God,
I think a lot of eyes will be on the BOUNTY

Could someone just create an app that does this?

bilboa1 said:
Since I installed JPK on a test phone after claims that the RFS related lag has been fixed.. well.. I'd like to share my impressions:
- I have installed approx 100 apps after the flash (flashed / wiped / factory reset btw)
A this point, the phone while slightly slower than one with Voodoo is pretty fast
A few days later, it's still good enough.
- 5 days later, lag starts to be felt, and it's stronger every next day until it becomes annoying to use
That's exactly the same experience as I had on various Eclair roms without any lag-fix. I also had this on JP3 (early Froyo).
So yeah. I looked into the /init binary from samsung and it's supposed to make some file system checks from time to time when you restart the phone, but it does not appear to really carry on with that.
So I ran the checks myself:
- you need a rooted phone, and adb or a terminal
- find all RFS partitions:
$ su
# mount|grep -i rfs
- kill all processes, go flight mode and remount them read-only
$ su (if you're not root.. not going to repeat it again for subsequent commands)
# kill -9 <pid> of anything that use the patrition
# mount -oremount,ro /dev/block/....
- check the RFS filesystem and correct errors
# /system/bin/fsck_msdos -p -f /dev/block/....
Surprise, a million of RFS errors fixed such as:
/path/to/file starts with free cluster FIXED
Cluster XXX continues with cluster XXX in FAT 0 but is marked free in FAT 1 FIXED
Detected cluster chain loop head XXXX for p XXXX FIXED
FSNext block XXX is correct NumClusters XXX FIXED (weird one)
No LOST.DIR FIXED
Lost cluster chain at cluster XXX YY clusters lost FIXED (prolly lost files/data here!)
Repeat for each partition
reboot the phone at the end
SURPRISE! It doesn't lag much anymore.
Use the phone an hour, do the check again and you will see it's already full of errors.
Conclusion:
RFS is bugged (we knew that didn't we) but it looks like it's fixable, if ever Samsung figures out what is corrupting the file system exactly (it's closed source so we can't really find out easily)
It might be possible to figure it out by looking at VFAT sources too.
I would be very interested to see if that fixes the lag for everyone or if i'm an isolated case and all my RFS partitions are on bad hardware or if it's really software corruption as I am guessing
Small disclaimer:
im not responsible for any data loss etc. no warranties etc. fixing file system even readonly might cause data loss due to the bugs in RFS. you've been warned lol.
Click to expand...
Click to collapse
VOLD is what does the RFS check at boot. It seems to run, although maybe it fails? It definitely does run though, you can check it running using 'ps' on phone boot. Maybe it's only cleaning up /sdcard though.
At any rate, running the disk check does help with speed, but it doesn't help that much. It's still slow. I think if you want to stick with RFS, you need to do a defrag as well as the filesystem check. After some use, RFS must be very very fragemented on most people's phones.
Even in perfect condition though, RFS still has some very nasty properties such as locking the entire disk when a write occurs, not doing buffering, etc etc.

INeedYourHelp said:
Could someone just create an app that does this?
Click to expand...
Click to collapse
An app can't do this, since the app would have to be running off RFS and would crash/have to be killed to perform the FS checks. It could be done on boot using some trickery and the playlogos / replace binary trick. Or it can be done by replacing the init script with some kernel hackery. But at that point, you might as well just use a real filesystem.
I guess a PC .bat file could be made that uses adb to do this for you and then reboot the phone... Doesn't seem worth the trouble though!

RFS is journelled. You sure the filesystem doesn't do the journaling properly?

Nice job figuring this out. Is someone forwarding all these findings to that Samsung dev?

It's not about RFS vs the other filesystems. I'm well aware of the performance of RFS. But it's decent enough when it's working properly. It's not nearly as fast as ext but fast enough that you don't get annoyed.
Thus fixing RFS would make the life of many people who aren't technically inclined better. If the RFS do get all corrupted everywhere, and Samsung figure that out and fixes it, it means a good thing for most people.
The rest of us will end up on ext anyways
And yeah I think the fscheck at boot fails, it must fail actually, i don't see how else it would happen.

bilboa1 said:
It's not about RFS vs the other filesystems. I'm well aware of the performance of RFS. But it's decent enough when it's working properly. It's not nearly as fast as ext but fast enough that you don't get annoyed.
Thus fixing RFS would make the life of many people who aren't technically inclined better. If the RFS do get all corrupted everywhere, and Samsung figure that out and fixes it, it means a good thing for most people.
The rest of us will end up on ext anyways
And yeah I think the fscheck at boot fails, it must fail actually, i don't see how else it would happen.
Click to expand...
Click to collapse
What firmware did you test on, btw? I've noticed that JPK does seem to take longer on the FS checks, so maybe they have it fixed already (doubt it though)?

RyanZA said:
What firmware did you test on, btw? I've noticed that JPK does seem to take longer on the FS checks, so maybe they have it fixed already (doubt it though)?
Click to expand...
Click to collapse
on JPK actually
im going to flash JM8 to see if its the same in fact, but i expect so

RyanZA said:
VOLD is what does the RFS check at boot. It seems to run, although maybe it fails? It definitely does run though, you can check it running using 'ps' on phone boot. Maybe it's only cleaning up /sdcard though.
Click to expand...
Click to collapse
I think VOLD only does the checks for the Internal SD and External SD, not the RFS partitions.
Interesting find though, about the FS errors.

I’ve been wondering why the lag appears after a couple of days. I suspected corruption in one way or another myself, as it stays after a reboot it could not have been RAM and there are no signs of running out of space. Thanks for your research and I hope it will lead to new fixes. Sad but true my fix is to reflash my phone almost weekly.
I run Doc's JPK super slim ROM which is really nice but still it lags, even with OCLF installed.
Yesterday I take my phone out of my pocket to take a quick photo. My phone wakes up and I sweep the glass. Halfway through the sweeping the animation stops. I wait patiently for a second or three and there my home screen is. (No widgets, no animations, just a single home screen with 12 icons on it of the applications I actually use). I click on the camera icon and I wait another 5 seconds for the camera to realize it is not supposed to sleep on duty. I make a photo, the actual moment is already gone by now but hey I have the thing in my hand. It just takes another 5 seconds to store the photo.
It is like being in a hurry with a toddler with you. You want to go quicker but you can’t get angry cause the little thing just can’t go faster. It has to stop and wonder about life every once in a while.
I like my phone and I am sure it will grow up.

Very interesting findings! Sure hope Samsung sees this or this is forwarded to some Samsung techs.

Maybe move this to the development forum then it might get more traffic from people that can actually help.

borchgrevink said:
Very interesting findings! Sure hope Samsung sees this or this is forwarded to some Samsung techs.
Click to expand...
Click to collapse
do you really think Samsung is reading every thread here on XDA?
Sent from my GT-I9000 using XDA App

matty___ said:
do you really think Samsung is reading every thread here on XDA?
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
No need to be uppity my friend ;-)

Some further info on possible RFS fixes here:
http://forum.xda-developers.com/showpost.php?p=8445244&postcount=143
With the sync issue fixed, and corruption fixed with checks, RFS might just work 'okay'! It won't be as fast as EXT, but it should still work fine if we can sort out all the bugs! And we have a much better chance of getting Samsung to include these fixes in a new firmware too.
If we could get hold of Samsung somehow, and manage to convince them that they should
1) disable the always sync behaviour
2) do full filesystem checks at boot up (or provide a utility to do the checks)
then RFS should be A LOT more usable!

Could someone perhaps turn this into a .bat-file?

RyanZA said:
Some further info on possible RFS fixes here:
http://forum.xda-developers.com/showpost.php?p=8445244&postcount=143
With the sync issue fixed, and corruption fixed with checks, RFS might just work 'okay'! It won't be as fast as EXT, but it should still work fine if we can sort out all the bugs! And we have a much better chance of getting Samsung to include these fixes in a new firmware too.
If we could get hold of Samsung somehow, and manage to convince them that they should
1) disable the always sync behaviour
2) do full filesystem checks at boot up (or provide a utility to do the checks)
then RFS should be A LOT more usable!
Click to expand...
Click to collapse
That quite right, I noticed the sync issue also.
As for the corruption, 2 things should be fixed:
- fsck from init should actually fsck the partitions properly on boot (we can sort of fix that by calling it in a script again)
- corruption should in theory not even happen so Samsung would have to work on RFS for that one
I ran JM8 for 2 days now and my rfs partitions are full of errors, like in JPK, just for confirmation if there needed to be one.
In fact it's still running fsck on /system as I'm writting and issues are filling the terminal .. its been running for 30s already lol

woeds said:
Could someone perhaps turn this into a .bat-file?
Click to expand...
Click to collapse
I haven't tried that but it might be easier to enable adb over usb (in development settings) then .. make sure you are rooted, type that:
> adb shell
$ su
#
<prompt on the phone for root, click allow>
reboot into recovery
> adb shell
$ su
# mount -oremount,ro /dev/block/stl9
# mount -oremount,ro /dev/block/stl10
# mount -oremount,ro /dev/block/stl11
<for safety i'm not including stl3 it's the EFS)
if there's any error due to "filesystem busy" them stop there, it means it doesn't work
otherwise:
#/system/bin/fsck_msdos -p -f /dev/block/stl9
#/system/bin/fsck_msdos -p -f /dev/block/stl10
#/system/bin/fsck_msdos -p -f /dev/block/stl11
# reboot

[HELP] Modifying mount point of EMMC.

What I need...
Someone to repackage a boot.img for me. Specifically, I need a boot.img unpacked, replace the file "/init.inc.rc" with my version, and repack it. (I'm stuck on all Windows, and cygwin is not an option.)
Purpose/Goal
Fix the annoying fact that /emmc is not accessible to almost all market apps, without resorting to using the modified media scanner from CyanogenMod or anything else drastic.
Do not change fstab. /mnt/emmc and /mnt/sdcard will not change.
NOTE: I am not trying to create a symlink on the FAT32 of the SD card.
My idea
Modify /init.inc.rc to change the EMMC settings. (Changes made, need someone with tools. See above.)
Modify /system/etc/vold.fstab to relocate EMMC mount point.
Directory structure
/sdcard (unchanged)
/sdcard/emmc (new location of emmc)
/emmc (Retarget the symbolic link to new location.)
/mnt/emmc (Change to symlink for compatibility, just in case.)
What I want to know...
This arrangement makes /emmc redundant. Can it be safely removed?
When you connect to a PC, how/what does Android map to USB drives? (I assume it is the mount blocks, not the symlinks.)
What odd behaviors may occur? (e.g. will "Settings->SD & phone storage" freak out?)
Maybe, just maybe: How to bottle this into a flashable .zip? (I'll worry about that later.)
If anyone has any pull with the ROM devs (i.e. Koush, rmk40, et al.), I really want to hear from them.

+1. I'd love to make emmc usable in Winamp

Bzzzt... Sorry.
ARGH!
The internal storage is VFAT also. No symlinks allowed.
Blast you, HTC!

What??
I hate doing this, but editing the original post doesn't bump the thread.
I did not want to create a new thread, but what I need has completely changed.
So. BUMP.

Why HTC, WHY?!
Would there be a way to format emmc to NOT be VFAT?

Progress!!!!
I'm close to getting a boot.img ready to test out on my phone.
I spent yesterday hacking away. I've made a Windows tool for handling boot images. I'm about 80% done with the required features. I have all the unpacking finished. I've repacked the ramdisk. I can generate the SHA hash to sign the image. It's just a matter to gluing the last stages together.
ppd0526 said:
Why HTC, WHY?!
Would there be a way to format emmc to NOT be VFAT?
Click to expand...
Click to collapse
I'm sure it could be done, but this is way more work/hassle that I want to deal with. Major obstacle here is that ALL data on emmc is wiped, and I'm not willing to that.
Assuming there are no hidden "features," my approach should be invisible to the Android layer (i.e. will not break any HTC software). HOWEVER... I'm pretty much Senseless, so I'm not too concerned (for my own use) about HTC's apps.
My biggest concern is that the media scanner will generate duplicates of all files found on emmc. But a/the big motivator for this work is to use Winamp, so I don't really give a whoop.

This was tried by koush when we couldn't get cm6 to scan emmc. It didn't work.
Sent from my ADR6300 using XDA App

distINCtINC said:
This was tried by koush when we couldn't get cm6 to scan emmc. It didn't work.
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
What didn't work? Or how did it not work?

I'm not sure. I wasn't involved in the effort. Koush would be the person to talk to but island how to get a hold of him. I just think the OS rejected mounting a physical drive within a physical drive. But don't let that discourage you. It might be still be possible.
Sent from my ADR6300 using XDA App

Any progress on this? I really would love to have /emmc accessible as /sdcard.
Why HTC decided to make /data/data so small and put the rest of the space as /emmc is still a mystery to me. This is my only gripe with this phone.

Progress update
I made my first attempt on Friday, which resulted in a boot loop. So, obviously, I'm missing something important. (Battery pull and recover boot fixed the problem.)
I couldn't work on it this weekend. But I'm going to start digging into it some today.
More info:
It didn't get past the slash screen. Since I'm flashing a boot image, this is obviously where the problem is located. I just don't have any error logging to read over. Since I'm cooking on Windows, I'm wondering if my file permissions and ownership are messed up.
Also, while running my update, I observed that the boot image flashing did not seem to take long at all. So, I'm concerned that I didn't even get a complete flash.

weareallkosh said:
I made my first attempt on Friday, which resulted in a boot loop. So, obviously, I'm missing something important. (Battery pull and recover boot fixed the problem.)
I couldn't work on it this weekend. But I'm going to start digging into it some today.
More info:
It didn't get past the slash screen. Since I'm flashing a boot image, this is obviously where the problem is located. I just don't have any error logging to read over. Since I'm cooking on Windows, I'm wondering if my file permissions and ownership are messed up.
Also, while running my update, I observed that the boot image flashing did not seem to take long at all. So, I'm concerned that I didn't even get a complete flash.
Click to expand...
Click to collapse
That doesn't bode well so far.

just some info
i'm not sure if this will help any of you, but i read before that it said koush tried to get the emmc mounting.. etc... and it didn't work. but - i'm running cm 6.1 stable and winamp can and does read my music found on the internal memory. so it seems to work for me. however - i cannot take picture and have them stored on the internal memory. anyway, good luck.

OK.... I got the ramdisk sorted out. The boot loop is gone. But it doesn't progress past the splash1. sigh.
I need to see the kernel messages, and typically ADB is not available.
drwndphish said:
just some info
i'm not sure if this will help any of you, but i read before that it said koush tried to get the emmc mounting.. etc... and it didn't work. but - i'm running cm 6.1 stable and winamp can and does read my music found on the internal memory. so it seems to work for me. however - i cannot take picture and have them stored on the internal memory. anyway, good luck.
Click to expand...
Click to collapse
CM6 uses a modified media scanner (Android layer) that uses '/mnt' as its base directory, instead of '/mnt/sdcard.' And, as you say, it has its own problems.
I am trying to modify the underlying file system to make hopefully all software work (e.g. HTC stock, Winamp and other media players, 90% of the apps I've played with).

It "works!"
Alright... I have all the tools made, and bugs squashed. So, I can correctly mod a boot image. (Tip: The boot process has a zero warning or error tolerance.)
It fully booted. BUT... A permanent notification "Preparing phone storage.../Checking for errors." did not go away. All emmc directories were absent.
So, I've found a problem. Google didn't return any useful information... Especially annoying is the face that I don't even get a link to the Android source to even get a hint where this notification comes from.
AHA! Fixed that problem. Now, emmc is visible on the sdcard.
NEXT problem (this one I expected):
Media scanner picked up 2 copies of my pictures (I have them on emmc). So, my thought is to start removing links (and references) to emmc in its new location until things clear up.

weareallkosh said:
Alright... I have all the tools made, and bugs squashed. So, I can correctly mod a boot image. (Tip: The boot process has a zero warning or error tolerance.)
It fully booted. BUT... A permanent notification "Preparing phone storage.../Checking for errors." did not go away. All emmc directories were absent.
So, I've found a problem. Google didn't return any useful information... Especially annoying is the face that I don't even get a link to the Android source to even get a hint where this notification comes from.
AHA! Fixed that problem. Now, emmc is visible on the sdcard.
NEXT problem (this one I expected):
Media scanner picked up 2 copies of my pictures (I have them on emmc). So, my thought is to start removing links (and references) to emmc in its new location until things clear up.
Click to expand...
Click to collapse
The double items in media scanner seems like a small issue compared to what it fixes.

More problems created than fixed. (And WHY this is a mess to begin with.)
Postmortem thus far...
Touching ANY code related to where emmc appears will cause Setting to FC if you view the SD & phone storage usage.
Makes media visible to "other" applications, but shows duplicates in HTC's music and gallery apps.
I didn't look too closely at it, but I question that the camera was playing nice with the new config.
ppd0526 said:
The double items in media scanner seems like a small issue compared to what it fixes.
Click to expand...
Click to collapse
SO... I took some time to understand the double items, and why EMMC is such a problem to begin with.
HTC did not modify the media scanner/provider to support EMMC. They modified their APPS. Do a dump of HTC's music and gallery apps. You'll find a LOT of extra code, and a lot of added symbols/strings for handling the phone storage.
In other words, they didn't create a "public" solution. They just made their own private patch, and brushed it under the rug. (How dare we not use THEIR apps???)
Media Scanner/Provider:
I looked at Koush's code changes. I don't understand his changes. I'm not sure how/why it "works." I don't know why it reportedly breaks the HTC apps. I am also not sure that their is a way to mod it to actually fix the issue... Google's code was not written to be extensible. But, I think it may be the way to go in the long run.
What other phones have EMMC? Do they have a fix?

My tools...
There is a lot of code duplication, no GUI, or options. It ain't exactly pretty, but it works.
I'm posting this here for future reference by others wishing to work with boot.img.
Note: This specifically targets 1 file on the ramdisk (init.inc.rc), but with some changes this could do almost anything you would want.
License... Oh. GPL. If you make changes, please send me a patch.
REQUIRES: AutoHotkey (Hey.... it's all I had available, but the code should be easy for anyone to follow and port to another language.)
Runs on Windows (XP). Does not require cygwin. Native GZIP included.

[Q] Why even after a full wipe does it say I have low memory....

So I had rooted my Htc Evo 4g and I would try new ROM's maybe once a week or so... And than I flash a ROM and go to install some apps and I get a low memory warning. I used to have that problem with my Hero. I did the full wipe (everything 3x) and I was wondering why I would be low on memory after clearing everything? Is there something I'm missing, lol?!!

Are you using A2SD with an ext partition? And if so, are you wiping EXT as well? I know you said everything, just checking.

I have never had that problem, and I regularly have around 100 or so apps on my phone.
What roms are you trying? I have tried most roms on here, and almost all of them actually use LESS space then the stock rom, as they get rid of things you dont need.

Bad clusters?? Look at the recovery.log after a wipe

bkrodgers said:
Are you using A2SD with an ext partition? And if so, are you wiping EXT as well? I know you said everything, just checking.
Click to expand...
Click to collapse
Lol... Actually I've never wiped that but I don't use the A2SD or anything so it never crossed my mind...

gpz1100 said:
Bad clusters?? Look at the recovery.log after a wipe
Click to expand...
Click to collapse
What is and how do I check the recovery log? Sorry for the newb question, you'd think I'd know by now, lol!!!

By bad clusters I assume he means bad blocks. It sounds like parts of your memory have become damaged simply through normal use, its inevitable in all solid state memories. Supposedly some evos have been shipped with defects that cause lots of bad blocks. If your hardware version is 0003 or lower there's a chance yours was one.

Davidsr1127 said:
What is and how do I check the recovery log? Sorry for the newb question, you'd think I'd know by now, lol!!!
Click to expand...
Click to collapse
Recovery.log is generated at /tmp/recovery.log whenever you do something in recovery. In recovery, if you go to advanced and then select report error it will copy that file to /sdcard/clockworkmod/recovery.log.
I doubt you'll find anything about bad blocks in that file. I just generated one and looked through it and the only thing about blocks that it says is "successfully wrote to block 0", which is just one block out of thousands. Its mostly technical things like what version of recovery you have, what radio your using things like that. It wouldn't hurt to look through it though. Some of it wont make sense, some will. Just look through line by line, it'll take like 5 minutes.

Davidsr1127 said:
What is and how do I check the recovery log? Sorry for the newb question, you'd think I'd know by now, lol!!!
Click to expand...
Click to collapse
Yes, I did mean bad blocks, but had sectors and clusters on the mind
Type the following from a dos prompt in the folder containing adb
adb shell
df
Paste the results into a reply. This will show us just how much free space you have and where.

ROM for AT&T

Got my Note 2 in today .. any ROM's known working with this hardware ? I'd read there might be issues with so many different versions of this device.
Thanks !

Sorry, but the i317 doesn't have any ROM. Not a single byte of it.
Perhaps you were asking about firmware?

garyd9 said:
Sorry, but the i317 doesn't have any ROM. Not a single byte of it.
Perhaps you were asking about firmware?
Click to expand...
Click to collapse
Interesting point. What are the firmwares stored in inside these modern devices? Are they not EEPROMs or some variant that are being flashed?

Non-volatile random-access memory.
All the memory in the device is one big pool similar to an SSD drive (even if its partitioned and mounted to appear otherwise.)
EEPROM would be WAY too slow (and wouldn't have the endurance.) Also, with EEPROM, you'd have to effectively erase and reformat all the device memory every time you got a new email message, logged a phone call, etc. (No random access with EEPROM.)
Yeah, I'm old.
Understanding the firmware... imagine shoving an SSD drive into a machine and making 2 partitions. The first you call "C" and install windows on. Then you create another partition ("D") to use as a data drive. You hack windows so that all writes are redirected to D. Now only mount the C drive as ro and mount D as rw.
This is easier with linux... first logical contains /usr, /etc, /home. /home contains mount points for the second logical that's mounted rw. Any time the firmware changes, the first drive is remounted as rw, changes made, and remounted as ro again.

ohRonaldo said:
Interesting point. What are the firmwares stored in inside these modern devices? Are they not EEPROMs or some variant that are being flashed?
Click to expand...
Click to collapse
I think his point of the question is that ROM usually would be a new aftermarket offing, say CM10 etc. And the Firmware refers to the Sammy official stock load or image (TAR?) that is flashed in ODIN or perhaps Keis.
I don't think that was a discussion on hardware.

ZedZardoz said:
I think his point of the question is that ROM usually would be a new aftermarket offing, say CM10 etc. And the Firmware refers to the Sammy official stock load or image (TAR?) that is flashed in ODIN or perhaps Keis.
Click to expand...
Click to collapse
How are they different? Either mount as /system and perform the same function. They are both firmware.
ROM means "read only memory." If it was actually ROM, it couldn't be modified.
If it'd help, I'd be happy to recompile CM10 for the i9300 and wrap it up in an ODIN compatible tarball.

garyd9 said:
How are they different? Either mount as /system and perform the same function. They are both firmware.
ROM means "read only memory." If it was actually ROM, it couldn't be modified.
If it'd help, I'd be happy to recompile CM10 for the i9300 and wrap it up in an ODIN compatible tarball.
Click to expand...
Click to collapse
Agreed. Just bits programmed to a memory.
garyd9 said:
Sorry, but the i317 doesn't have any ROM. Not a single byte of it.
Perhaps you were asking about firmware?
Click to expand...
Click to collapse
Now that I re-read your post, I see that it was a discussion of hardware. But aren't you just quibbling on symatics?
Off-topic> Is there a way to dump the TAR off my new phone prior to root? I guess some day the official firmware will become available.

ZedZardoz said:
Is there a way to dump the TAR off my knew phone prior to root? I guess some day the official firmware will become available.
Click to expand...
Click to collapse
Not all at once. The stock kernel and stock recovery images are already extracted. What I'd suggest is this:
After you get your phone, use ODIN to install the root kernel referenced in this post: http://forum.xda-developers.com/showpost.php?p=33846420&postcount=163
Then adb shell into the phone, but when you do the dd thing, instead of pulling the recovery partition, you can pull the system partition. The commandline would be:
dd if=/dev/block/mmcblk0p13 of=system.img bs=4096
That will result in a huge (but completely stock) system partition image. That, combined with the recovery.img and boot.img (kernel) we already have can be used to get a system completely stock.
PS: I hope the community gets you a Note2 soon!
Click to expand...
Click to collapse
Why? I just sold an international note2 and am using an AT&T note2. If the community were to try to donate one to me, I'd tell them to take their money and donate it to some children that need food, clothes, etc.

garyd9 said:
Not all at once. The stock kernel and stock recovery images are already extracted. What I'd suggest is this:
After you get your phone, use ODIN to install the root kernel referenced in this post: http://forum.xda-developers.com/showpost.php?p=33846420&postcount=163
Then adb shell into the phone, but when you do the dd thing, instead of pulling the recovery partition, you can pull the system partition. The commandline would be:
dd if=/dev/block/mmcblk0p13 of=system.img bs=4096
That will result in a huge (but completely stock) system partition image. That, combined with the recovery.img and boot.img (kernel) we already have can be used to get a system completely stock.
Why? I just sold an international note2 and am using an AT&T note2. If the community were to try to donate one to me, I'd tell them to take their money and donate it to some children that need food, clothes, etc.
Click to expand...
Click to collapse
Thanks for the response.
Sorry the PS was ment for another thread... Damn all this time waiting on my delivery and too much thread watching / posting.

It *is* a variant of EEPROM. It is also a type of "non-volatile RAM" which is also a form of erasable ROM. It's much further from RAM than it is from EEPROM. RAM needs constant power to refresh it to prevent data loss and reading it is destructive, it degrades the contents and requires recharging time before being accessed again.
I thought I'd try to point it out in question form. The guy asked an innocent question using older but correct terminology -- I completely understand being in that position because I'm an old man, a traveling man, trying to figure this new stuff out too.

ohRonaldo said:
It *is* a variant of EEPROM. It is also a type of "non-volatile RAM" which is also a form of erasable ROM. It's much further from RAM than it is from EEPROM. RAM needs constant power to refresh it to prevent data loss and reading it is destructive, it degrades the contents and requires recharging time before being accessed again.
I thought I'd try to point it out in question form. The guy asked an innocent question using older but correct terminology -- I completely understand being in that position because I'm an old man, a traveling man, trying to figure this new stuff out too.
Click to expand...
Click to collapse
First, please stop referencing your age in every single post. We get it. You're old. You might actually be surprised to learn that quite a few other people here are old as well.
As for EEPROM or not, I actually still use EEPROM with some of my ham radio gear, and NVRAM is nothing like it in general use. In order to rewrite any portion of EEPROM, the entire chip has to be erased. (I made reference to that above.) Same issue with EPROM (but for a slightly different reason.) I agree it might be similar electrically, but from a usage point of view, "ROM" is nothing like "NVRAM."
Oh, and I'm old too. How old? Let's just say that I wrote my first computer programs, I was terrified of dropping the deck and getting the cards out of order.
Take care
Gary

That's why you draw a line across the top of the deck, Gary. HI HI
73

ohRonaldo said:
That's why you draw a line across the top of the deck, Gary. HI HI
Click to expand...
Click to collapse
yep. okay, I'll kill stop harassing everyone.
dit dit