Develop Bugs

[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.

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

[HOWTO] Optimal ext4 mount options

Hi guys,
Now that several lagfixes are using the ext4 filesystem, perhaps we should look at optimizing ext4 for performance and lifespan of the flash memory.
One of the main things we can change is the journaling method to data=writeback. This should reduce writes and improve performance at a slight expense of reliability. Quote:
"In data=writeback mode, ext4 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext4 performance."
One explanation here:
http://blog.smartlogicsolutions.com...ions-to-improve-ext4-file-system-performance/
Reference here:
http://git.kernel.org/?p=linux/kern...02ac5fa36d7f4c07856fe9cf89391e08986f7;hb=HEAD
HOW TO
1. Change the default mount option of the partition using tune2fs. You need to use a version of tune2fs that supports ext4, the one in busybox 1.17 does NOT. A working version is attached to this post.
- Push the tune2fs file to the phone's SD CARD:
adb push tune2fs /sdcard/
- Copy the tune2fs file to /data/
adb shell
su
cp /sdcard/tune2fs /data/
Now change the options:
/data/tune2fs -o journal_data_writeback /dev/block/mmcblk0p2
To verify:
/data/tune2fs -l /dev/block/mmcblk0p2
Look for the line that says:
Default mount options: journal_data_writeback
* Repeat the above for all other ext4 partitions.
It should take effect after a reboot. The next time it will be mounted automatically with data=writeback. You might have to do the tune2fs settings and reboot twice to get it to stick - I'm not sure why, but I had to.
You can verify this using the mount command:
# busybox mount | grep ext4
/dev/block/mmcblk0p2 on /data type ext4 (rw,noatime,barrier=0,nobh,data=writeback,noauto_da_alloc)
/dev/block/stl10 on /dbdata type ext4 (rw,noatime,barrier=0,nobh,data=writeback,noauto_da_alloc)
2. In addition to that, you can also edit the mount options to include the nobh option, which is a further minor optimization for data=writeback mode.
I personally use the options noatime,barrier=0,nobh,data=writeback. Voodoo already uses some of them like noatime and barrier=0.
I do it using a startup script (you need to know how to use/modify a startup script), with the following commands:
for k in $(busybox mount | grep ext4 | cut -d " " -f3)
do
sync
busybox mount -o remount,barrier=0,nobh $k
done
EDIT: Attached tune2fs that supports ext4. Works on Froyo kernels with ext4 support.

I posted the same request in another thread and i though it will be better if i do it here.
I found e2fsprogs-ext4.zip, but not sure if this is the correct zip.
it will be great if you can provide it here.
For others willing to try it, please change the /dev/block/mmcblk0pX to whatever you are using now.
my system is using /dev/block/mmcblk0p4

s88 said:
I posted the same request in another thread and i though it will be better if i do it here.
I found e2fsprogs-ext4.zip, but not sure if this is the correct zip.
it will be great if you can provide it here.
Click to expand...
Click to collapse
I've attached it here, it worked for me with the Universal Lagfix Froyo kernel that supports ext4.

hardcore said:
I've attached it here, it worked for me with the Universal Lagfix Froyo kernel that supports ext4.
Click to expand...
Click to collapse
And did you notice any improvements with new mount options?

busybox 1.17.1 says invalid option -o on tune2fs
==
i need the version attached to this thread, busybox version only supports ext2 and ext3

danzel said:
busybox 1.17.1 says invalid option -o on tune2fs
Click to expand...
Click to collapse
copy tune2fs into /system/xbin and chmod 755

Write back will cause data loses on crashes and it will increase read time on read miss since you need to write the block back to the main mem before reading a new block.

how & where do i edit mount options?

mdalacu said:
And did you notice any improvements with new mount options?
Click to expand...
Click to collapse
I didn't do any benchmarks, but in theory it should be better - reduced periodic journal writes (better battery life, flash lifespan and performance).

I don't know about performance but my SGS feels like a little bit snappier.
Thanks for this info.

chanw4 said:
Write back will cause data loses on crashes and it will increase read time on read miss since you need to write the block back to the main mem before reading a new block.
Click to expand...
Click to collapse
There is always a risk of slight data loss during crash, even with data=ordered. And we are already using some even more 'risky' options like barrier=0 and noauto_da_alloc anyway.
This setting increases the risk a bit more.

s88 said:
copy tune2fs into /system/xbin and chmod 755
Click to expand...
Click to collapse
He's referring to the busybox 1.17.1 version. It doesnt support the ext4 options. For the version attached here, you have to copy it to somewhere else like /data/ before u can execute it. You don't really need to copy it to /system/xbin.

hardcore said:
There is always a risk of slight data loss during crash, even with data=ordered. And we are already using some even more 'risky' options like barrier=0 and noauto_da_alloc anyway.
This setting increases the risk a bit more.
Click to expand...
Click to collapse
Yeah but I think at some point you're just throwing away the safety of EXT4, and might as well just use EXT2 since it writes faster even with these options on. (Can anybody confirm this? I did a check and EXT2 is still faster even with these mount options... while EXT4 reads faster. But writes are more important than reads on MoviNAND from my usability experience, since the reads are generally fast enough anyway.)

RyanZA said:
Yeah but I think at some point you're just throwing away the safety of EXT4, and might as well just use EXT2 since it writes faster even with these options on. (Can anybody confirm this? I did a check and EXT2 is still faster even with these mount options... while EXT4 reads faster. But writes are more important than reads on MoviNAND from my usability experience, since the reads are generally fast enough anyway.)
Click to expand...
Click to collapse
Hi Ryan, it's different. ext4 with data=writeback still uses journaling but only for metadata, which supposedly "provides a similar level of journaling as that of XFS, JFS, and ReiserFS".
So it's still safer than ext2 but without the speed (and more importantly, battery or flash write lifespan) impact full data+metadata journaling.
More detailed information in the sources here:
http://git.kernel.org/?p=linux/kern...02ac5fa36d7f4c07856fe9cf89391e08986f7;hb=HEAD

hardcore,
how do you change the mount options? like buffer from 1 to 0 and nobh, etc

s88 said:
hardcore,
how do you change the mount options? like buffer from 1 to 0 and nobh, etc
Click to expand...
Click to collapse
I've made a clearer procedure in the first post. To change some options you might need a startup script though.

hardcore said:
I didn't do any benchmarks, but in theory it should be better - reduced periodic journal writes (better battery life, flash lifespan and performance).
Click to expand...
Click to collapse
That sounds very promising
Followed the procedure - had to do it twice as well to make it stick...dont see any obvious changes in the last 5 minutes. Will update after using it for a while.
PS: how persistent is that setting? what circumstance does it get reset? When a new kernel is installed?

Does it work with 2.1 too?

bobbel said:
Does it work with 2.1 too?
Click to expand...
Click to collapse
yes, it does. I am using JM9, and it feel faster.
take note i only change the data to write_back, haven't figure out a way to do the rest.
for write back, it can be done on the terminal emulator.

s88 said:
yes, it does. I am using JM9, and it feel faster.
take note i only change the data to write_back, haven't figure out a way to do the rest.
for write back, it can be done on the terminal emulator.
Click to expand...
Click to collapse
Cool, I give it a try.
One Question:
When I enter the mount cmd I have:
/dev/block/mmcblk0p4 /data ext4 rw,noatime,...
So I have to use
/data/tune2fs -o journal_data_writeback /dev/block/mmcblk0p4 (instead mmcblk0p2)
Right?

[MOD] How to replace /cache partition with a virtual one (any size)

I found a solution to temporarily replace the /cache partition with a virtual one having any arbitrary size.
I made a script that creates an empty file (64MB but it can be larger) on /data/local. Then it creates an ext4 filesystem on the file, unmounts the /cache and finally mounts the file as the cache partition through the loop device.
This virtual partition works until the next reboot and then the old /cache partition is mounted again.
To test this, copy the script to your phone give it executable permissions and run it through adb shell or a terminal. You have to be root and have busybox installed
I tested the script on stock JVQ, Semaphore kernel and works OK.
You may find a CWM edition (thanks to corgar) here. This version will create the cache partition (50 MB) in the /dbdata.
Use this script only if you know what you are doing and with your own risk!.

What does this do exactly? Does it take part of the flash memory to use as cache instead of RAM? I dont know much about advanced hacking etc, but this sounds like it could fix my constantly restarting apps when there are too many apps opened at the same time, or too many processes running at the same time. or are those things unrelated with this?

neswii said:
What does this do exactly? Does it take part of the flash memory to use as cache instead of RAM? I dont know much about advanced hacking etc, but this sounds like it could fix my constantly restarting apps when there are too many apps opened at the same time, or too many processes running at the same time. or are those things unrelated with this?
Click to expand...
Click to collapse
No, it creates a file in the /data partition and mount it as cache. I don't think that this will solve you the problem.
I made it mostly for people who want to download applications more that 30 MB from market

Nice idea @stratosk! I must give this a try!

Anyone tried this?
Please for your feedback.

I'm ready to test during the day. Do you have any name of a free app bigger than 30 Mb we can download to validate it works?

I've runned the script with SGS Tools. It runs ok, and creates a bigger cache partition, but i still can't download bigger apps on market, although it now gives me a different error (before was something like: There isn't space on this device. And now it is something like: There was an error). Tried with "Battle Bears 1 Lite" and "Extreme Formula"
EDIT: is it ok to run with SGS tools? I don't know how to run them in Terminal! Someone could tell me how?
EDIT 2: Actually i've tried now, and i can't download any apps from market!

lucbl1 said:
I've runned the script with SGS Tools. It runs ok, and creates a bigger cache partition, but i still can't download bigger apps on market, although it now gives me a different error (before was something like: There isn't space on this device. And now it is something like: There was an error). Tried with "Battle Bears 1 Lite" and "Extreme Formula"
EDIT: is it ok to run with SGS tools? I don't know how to run them in Terminal! Someone could tell me how?
EDIT 2: Actually i've tried now, and i can't download any apps from market!
Click to expand...
Click to collapse
Are you sure you have enough space on /data ?

stratosk said:
Are you sure you have enough space on /data ?
Click to expand...
Click to collapse
Yeah, pretty sure.
I've rebooted my device now, and downloads work fine again, except of course of those bigger than 30mb (actually 26mb, since ext4 conversion uses 4mb on cache).
PS: thinking about it now, could it be that the 4mb of ext4 conversion is keeping me from downloading the apps properly?

Just modified that script to move cache in dbdata ( onenand). A little request how to mount without specify fs? Instead of mount -t ext4. Thx
Inviato dal mio GT-I9000 usando Tapatalk

corgar said:
Just modified that script to move cache in dbdata ( onenand). A little request how to mount without specify fs? Instead of mount -t ext4. Thx
Inviato dal mio GT-I9000 usando Tapatalk
Click to expand...
Click to collapse
I have to test this, because the script makes ext4 file system on the cache.img. So it should be mounted as ext4

lucbl1 said:
Yeah, pretty sure.
I've rebooted my device now, and downloads work fine again, except of course of those bigger than 30mb (actually 26mb, since ext4 conversion uses 4mb on cache).
PS: thinking about it now, could it be that the 4mb of ext4 conversion is keeping me from downloading the apps properly?
Click to expand...
Click to collapse
I'm not sure about this.
If you don't use this remember to delete the cache.img file from /data/local because it's 64MB

If i delete the conversion and want to make the script dynamic? Mount rfs if rfs or mount ext4 if ext4. Dbdata is converted by kernel and by user decision so making it dynamically check is a must have i think.
Inviato dal mio GT-I9000 usando Tapatalk

corgar said:
If i delete the conversion and want to make the script dynamic? Mount rfs if rfs or mount ext4 if ext4. Dbdata is converted by kernel and by user decision so making it dynamically check is a must have i think.
Inviato dal mio GT-I9000 usando Tapatalk
Click to expand...
Click to collapse
Actually you may have dbdata in rfs and the file system of the cache.img could be ext4. You make and independent file system on this file

ok after some testing and tuning up, and since market apps can go up to 50mb maximum, and dbdata is on fast onenand i've modified a bit your script.
Code:
#!/system/bin/sh
#
# stratosk - 27/07/2011
# Corgar - 28/07/2011 ( changed location of cache in dbdata for onenand i/o, decreased cache dimension to 50mb )
# Remount /cache partition with a larger one (54.5 MB / 50mb cache)
# create a file 54.4 MB
dd if=/dev/zero of=/dbdata/cache.img bs=1024 count=55808
# create ext4 filesystem
mke2fs -F -T ext4 /dbdata/cache.img
# unmounting old cache partition
umount /dev/block/stl11
# mount
losetup /dev/block/loop7 /dbdata/cache.img
mount -t ext4 /dev/block/loop7 /cache
chown system.cache /cache
chmod 770 /cache
here are the script to push in /system/init.d folder. i'm not making a cwm flashable zip because is still in test version and i prefer at the moment to be used only by "veteran" user.
thx anyway to stratosk.
Download Here!

Nice script !
But why not make it on the sdcard ?
It should not have any problem there regarding space issues.

sdcard is mounted and checked after fs integrity check.
sdcard is slow compared to onenand memory. also sdcard is more fragmented than internal memory.

Any feedback?
Anyone tried this?

Running flawlessy on my custom rom. Very nice job indeed. Thx man. If you need a link Just ask but It's only for italian customer.
Inviato dal mio GT-I9000 usando Tapatalk

corgar said:
Running flawlessy on my custom rom. Very nice job indeed. Thx man. If you need a link Just ask but It's only for italian customer.
Inviato dal mio GT-I9000 usando Tapatalk
Click to expand...
Click to collapse
Glad to hear that
Did you test it on market applications > 30 mb?
Thanks for feedback.
P.S. with similar manner you can make portable (and maybe encrypted) filesystem. Create a file mount it as filesystem, write anything you want in it, then umount and mount somewhere else... Even in other phone or in your linux box
Edit: yes please send me the link

[Guide]Functional ext4 for external microSD with just a few bumps left

Y.G. said:
I formated my sd card to Ext4 and when insert it in to my phone, it says that's it's blank and has unsupported files. Any reasons for that?
Sent from my SPH-L710 using xda premium
Click to expand...
Click to collapse
The SPH-L710 Samsung Stock LJ7 TW 4.1.1 Android doesn't understand/support the change to ext4 external SD card (microSD) without a few things being done.
I'm working this out right now. So far I have manually been able to mount the newly created ext4 partition on the microSD card through adb, and after some chown/chmod I was able to go back to "Settings and Storage" and the "Mount SD Card" picked it up, and I was up and running ext4. But this didn't persist after a restart. So I'm looking into: /etc/vold.fstab MODS to keep it after restart right Now !!
If Some one else already has this perfected please chime in. I'm wanting to do most of the devices in the house this way when I get time because better performance, having a file system with a journal, and getting rid of thins like 4 Gig per file limitations is pretty Sweet in my humble opinion *Grin*
0) Assuming you already have your microSD card formatted ext4. I also happened to label mine extSdCard for the volume label within gparted
1) Can mount with:
mount -w -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard/
2) To get the correct owner and permissions run:
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
3) Should make the extSdCard owner/permissons match the regular internal sdcard you can verify this like so:
cd /storage/ && ls -l
drwxrwxr-x root sdcard_rw 2013-01-12 18:16 extSdCard
drwxrwxr-x root sdcard_rw 2013-01-12 17:05 sdcard0
4) After that you can go to the "Settings and Storage" to run "Mount SD" and you will have ext4 extSdCard Show up and it bring up the File System Status !! --> Until you reboot and it goes to crap because I don't have the vold.fstab edit/MOD complete _yet_ ... So, for now a boot script has been put in place to bring our external SD card back online during restart, so the system will acknowledges it, making the world a better place.
Example of how things look file system wise: mount | grep extSdCard
/dev/block/mmcblk1p1 /storage/extSdCard ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
5) Have not been able to resolve the vold.fstab to make this ext4 extSdCard matter fully Legit (in my opinion), but I did manage to make it remount the card on boot, so its online when the system comes up instead of having to manually mount it. Did this by -->
Added the following lines to the very bottom of: /etc/init.qcom.post_fs.sh
## sponix MOD to match with ktoonz kernel for better power management
stop mpdecision
## sponix MOD to mount extSdCard prior to GUI work around to make ext4 function
## read and write extSdCard mount
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
mount -w -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard
chown root:sdcard_rw /storage/extSdCard
chmod 775 /storage/extSdCard
## if you want read only extSdCard mount
## mount -r -t ext4 /dev/block/mmcblk1p1 /storage/extSdCard
Still attempting to automate the process so the Stock+root LJ7 can pick up the extSdCard _normally_ without having to do the mount command manually, but so far its kicking my butt. Also this is more a "General, or Question and Answer type Topic" the Kernel(s) obviously support ext4 the system fs uses/requires it *Grin*.. So we might get Our Friendly Neighborhood Moderator to Migrate it to the proper place to help others. Just hoping to get the last few bumps smoothed out, or find someone that already documented the process that I've overlooked *Grin*..
Current Known Issues: If you unmount the card through the "Settings | Storage | Umount SD" or by hand with umount, you will either need to reboot for it to reattach through the /etc/init.qcom.post_fs.sh boot script script addition, or will have to mount it manually if you want to keep the system up and running. Guess you could also probably just run the /etc/init.qcom.post_fs.sh as root from a terminal emulator (or adb).
Still searching for vold.fstab bits of wisdom but that will have to continue next weekend -->
Sexy and You Know it,
Keep on Flashing,
sponix2ipfw (sponix
:fingers-crossed:

Ha! Sorry. Deleted: Didn't understand that you had it running on boot (can't read properly )

Great idea
Am I really the only one who also thinks this idea is the nuts?
Am I the only one who longs to transform the mess that passes for a filing system on the internal sd using symbolic links into a beautifully organized, encrypted and cloud synced system on my external sd?
Is it just me and a few others that want to be able to achieve the above so that we can move from one ROM to another or recover from a lost phone with the minimum of fuss?
Are we freaks? :cyclops:
Say it isn't so XDA!! :crying:
I'm gonna try this on my international S3 running Null_ Rom 25 JB 4.1.2
PS do you have any idea how the entire ExtSD or just a folder can be enrypted using Cryptonite and automatically mounted at boot time?

emp111 said:
PS do you have any idea how the entire ExtSD or just a folder can be enrypted using Cryptonite and automatically mounted at boot time?
Click to expand...
Click to collapse
Is this along the lines of what you're looking for?
http://forum.xda-developers.com/showthread.php?t=1141467
Also your idea is pretty insane, but also genius
If you get that to work please do come back and share

Insane ideas are the best lol
CNexus said:
Is this along the lines of what you're looking for?
http://forum.xda-developers.com/showthread.php?t=1141467
Also your idea is pretty insane, but also genius
If you get that to work please do come back and share
Click to expand...
Click to collapse
Thank you for your prompt reply, yes it is asking a lot I know but I think that it can be done.
Now if you really thought that idea was insane......check this out:
Imagine that we asked every Android app developer to submit the various paths used for their config (and config backup) files to a central database and had the ability to add or own custom paths (which could be added to the central database once approved).
We could build an script/app that would retrieve a list of currently installed apps on your phone then automatically build a symbolically linked file system (and/or backup file system) in the location of your choice that you could either encrypt and/or sync using your current tools or even incorporate this functionality into the app itself along with the ability to choose what was encrypted/backed up and how i.e. either synced to the Cloud or (S)FTP or SMB as either a dd copy or even a cwm flashable zip.
Could I dare hope for a Tasker module or the ability to add custom scripts?
I wish I could do this myself but my coding skills are non existent
Anyway the LUKS manager app won't automatically mount a file system, but I really like it anyways, thank you for pointing me to it!
And on the Ext4 front, the mount command (yes the 1st one ) failed, maybe the op could offer a suggestion. :angel:
BTW is there a place for people to suggest ideas for apps here?

Wait really it wont? I couldve sworn I remembering that it did
But dude....
You need to learn yourself some java and start whipping stuff up
Idk about the whole central database thing, but the rest could definitely be done with root access
I think the main problem with that is the proprietary aspects...i mean even here on XDA where binaries released are supposed to be GPL compliant, many of them arent and its sad because it deteriorates the overall quality of work thats released afterward

This whole thing is just hard work!
CNexus said:
Wait really it wont? I couldve sworn I remembering that it did
Click to expand...
Click to collapse
Doesn't seem to unfortunately
But dude....
You need to learn yourself some java and start whipping stuff up :D :D[/QUOTE said:
You make it sound soooo easy lol, and at another point in my life maybe it would have been but right now I'm operating at a reduced level due to some unforeseen circumstances that have left me lacking focus, motivation etc
You know all the things you need to be creative, learn etc lol
Anyway back to the matter at hand, I have got my ext4 SD card to the stage where I have to manually mount it from within the Settings/Storage as I'm using the international S3 and don't have the init.qcom.post_fs.sh, I think the qcom refers to Qualcomm chipset in US S3's.
As for modifying vold.fstab so we can avoid the above workaround it would seem that maybe thats a dead end as according to a German guy on android-hilfe. de, Vold may have been modified by Samsung to only deadl with exFAT on External SD's.
Looks like I'm not gonna be in Android nirvana for a while :crying:
Unless anyone else on XDA fancies getting in on this !!!!
Click to expand...
Click to collapse

Got it working ..... kinda
Got an app called ezymount (by ezynow) that automounts my ext4 64GB microSD at boot time.
I have to wait a few seconds for the boot process to complete but it's automatic, am pretty happy!!
Now gotta get symlinks, encryption and cloud synchronization sorted :/