99% of the problems users are having with Apps2SD are caused by the unclean shutdown of the ext2 filesystem, because Android does not unmount it when rebooting or shutting down the system, and there are no tools on the device to fsck the filesystem on boot. Ext3 is journaled and this isn't an issue because the journal will simply replay on boot.
I'd like to put an end to this.
Attached is e2fsprogs (tune2fs, e2fsck, resize2fs, and mke2fs) built for Android/ARM. You should also use the "-t auto" mount option so that it's still backwards compatible with ext2.
To convert your ext2 to ext3, you can simply run "tune2fs -j /dev/block/mmcblk0p2" after you have these tools on your device, and reboot (assuming your ramdisk allows for mounting as "auto"). You should unmount and e2fsck the partition first, if it's not been checked for errors.
Step by step by neoobs
can we have a noob-friendly guide to this preferably through terminal.
cyanogen said:
99% of the problems users are having with Apps2SD are caused by the unclean shutdown of the ext2 filesystem, because Android does not unmount it when rebooting or shutting down the system, and there are no tools on the device to fsck the filesystem on boot. Ext3 is journaled and this isn't an issue because the journal will simply replay on boot.
I'd like to put an end to this.
Attached is e2fsprogs (tune2fs, e2fsck, resize2fs, and mke2fs) built for Android/ARM. You should also use the "-t auto" mount option so that it's still backwards compatible with ext2.
To convert your ext2 to ext3, you can simply run "tune2fs -j /dev/block/mmcblk0p2" after you have these tools on your device, and reboot (assuming your ramdisk allows for mounting as "auto"). You should unmount and e2fsck the partition first, if it's not been checked for errors.
Click to expand...
Click to collapse
Will this work with ADP JF1.5?
Before I try it, let me get a few things straing. I have to put these files in the corresponding folders, reflash, then type type the commands from terminal on the phone? Or does this have to be done with adb?
Beast84 said:
Will this work with ADP JF1.5?
Before I try it, let me get a few things straing. I have to put these files in the corresponding folders, reflash, then type type the commands from terminal on the phone? Or does this have to be done with adb?
Click to expand...
Click to collapse
its already working for ADP. I have both my phones running on EXT3 and I havent found a problem. Its more reliable and I have gotten a Force Close or Wait screen with all the speed his build has.
cyanogen said:
To convert your ext2 to ext3, you can simply run "tune2fs -j /dev/block/mmcblk0p2" after you have these tools on your device, and reboot (assuming your ramdisk allows for mounting as "auto"). You should unmount and e2fsck the partition first, if it's not been checked for errors.
Click to expand...
Click to collapse
Huh?
Can you explain this in English please?
Henchman said:
Huh?
Can you explain this in English please?
Click to expand...
Click to collapse
I mainly intended this for other ROM makers, so they can incorporate these features into cooked ROMs.
So this basically means all of us with ext2 partitions will have to get a new card or is there anyways for us to convert to ext3?
djdeviance said:
So this basically means all of us with ext2 partitions will have to get a new card or is there anyways for us to convert to ext3?
Click to expand...
Click to collapse
please re-read the first post.
"To convert your ext2 to ext3, you can simply run "tune2fs -j /dev/block/mmcblk0p2" ....
pershoot said:
please re-read the first post.
"To convert your ext2 to ext3, you can simply run "tune2fs -j /dev/block/mmcblk0p2" ....
Click to expand...
Click to collapse
Yes I did read that and tried as well. Was unsuccessful that why I asked.
Premature SD failure from frequent journal commits?
I wondered why this solution wasn't inplemented from the beginning. However, In one of the threads on A2SD, I read that moving /DATA/DATA to SD would negatively affect the longevity of the SD cards because of the frequent write/re-write cycles of files in that directory, particularly sqlite database commits . One contributor suggested that a using a journalled filesystem in this context would have a similar effect in that there would be repeated writes to the specific area of the SD where the journal is stored.
Any thoughts on this?
Once we run the commands in terminal, will that wipe everything off the ext partition? Or will it just convert the ext2 to ext3 & leave all my apps intact?
sir*mez said:
its already working for ADP. I have both my phones running on EXT3 and I havent found a problem. Its more reliable and I have gotten a Force Close or Wait screen with all the speed his build has.
Click to expand...
Click to collapse
I am not on his build. I am on ADP JF1.5
Which is why I asked if it will work on JF's build & not his build. I know it works on his. He's the one who brought it up
arqueware said:
I wondered why this solution wasn't inplemented from the beginning. However, In one of the threads on A2SD, I read that moving /DATA/DATA to SD would negatively affect the longevity of the SD cards because of the frequent write/re-write cycles of files in that directory, particularly sqlite database commits . One contributor suggested that a using a journalled filesystem in this context would have a similar effect in that there would be repeated writes to the specific area of the SD where the journal is stored.
Any thoughts on this?
Click to expand...
Click to collapse
Most Class 6 cards support wear leveling these days.
Beast84 said:
I am not on his build. I am on ADP JF1.5
Which is why I asked if it will work on JF's build & not his build. I know it works on his. He's the one who brought it up
Click to expand...
Click to collapse
aaahhhh... ;p no i dont think jf has made his EXT3 compatable which is why cyangen is asking every dev to use EXT3.
Cyanogen
Can I put these files in my ADP JF1.5 update.zip & flash that? Or does something else need to be done to have it see the ext3 partition? Also your boot.img with the noatime change, can I put that in also? Or could you possibly take the boot.img from JF1.5 & change it for me?
ext3 is built in ;P
Code:
$ adb shell cat /proc/filesystems
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev debugfs
nodev sockfs
nodev pipefs
nodev anon_inodefs
nodev tmpfs
nodev inotifyfs
nodev devpts
ext3
ext2
nodev ramfs
vfat
yaffs
yaffs2
Your ramdisk needs to mount the partition with "-t auto" (or "-t ext3" if you don't want backwards compatibility) instead of "-t ext2" for it to be effective. My build is the only one that does this so far AFAIK. In the JF builds, you need to change the "runme.sh" script.
cyanogen said:
Your ramdisk needs to mount the partition with "-t auto" (or "-t ext3" if you don't want backwards compatibility) instead of "-t ext2" for it to be effective. My build is the only one that does this so AFAIK.
Click to expand...
Click to collapse
I'm guessing that wouldn't be an easy change to do? Well I guess I will have to try one of the new roms which supports this since JF doesn't update his releases like the other guys do
Beast84 said:
I'm guessing that wouldn't be an easy change to do? Well I guess I will have to try one of the new roms which supports this since JF doesn't update his releases like the other guys do
Click to expand...
Click to collapse
It requires a little bit of hacking.
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
cyanogen said:
It requires a little bit of hacking.
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
Click to expand...
Click to collapse
Wow all I see is matrix code! Thanks anyway I will read up, see what I can make of it. Thanks for pointing me in the right direction at least
SHORT: I need the filesystem block size (location would be nice too; however, I can guess that) so I can use e2fsck to restore my super-block.
LONG: I have been having issues for the past several days where I cannot umount /system. I thought it may have been a bad conversion going to/from or from/to rfs and ext4 and thought doing the conversion again had fixed it. But alas...it didn't.
I cannot umount the files system from adb ("device is busy" error) or CWMR ("Couldn't find valid filesystem superblock" in the log) on any version of ROM or using any kernel that I can find. Voodoo can seem to convert the filesystem (back/forth), but it only seem to work if I tell it to from the Voodoo Control and then reboot, which is odd. Still cannot umount.
When I try and use Navenedrob's Ext4 Formatter, it fails for /system. CWMR's log shows:
/tmp/tune2fs: Bad magic number in super-block while trying to open /dev/block/stl10
Couldn't find valid filesystem superblock
Should be fixable with e2fsck, if I can get the correct information from tune2fs.
Typically, the command should be:tune2fs -l /dev/block/stl10 OR tune2fs -l -L /system
That said, tune2fs is tell me "-l" is an unknown option.
Can someone who is familiar with tune2fs (or other filesystem tools) in the Android/BusyBox environment please post either the correct command or a list of the contents of the filesystem super-block? Please be sure to include if your /system is in EXT4 or RFS.
Man, I haven't see this **** in years. Even then, it was pretty exclusive to virtual/networked file system (e.g. LVM).
Any-who, much appreciated....
So, after sleeping on it, I came to realize an error in my thinking...
I cannot use e2fsck to fix an RFS filesystem. Even more upsetting is that I cannot seem to find anything on The Google about command line RFS tools. Guess I could try a conversion and EXT filesystem, then change the superblock, then convert back to RFS, but that seems awfully convoluted.
Suggestions?
I suggest you odin with pit and check repartition. That *usually* fixes everything.
Sent from my debloated ep1q charge......bro.
Thanks for the tip...I probably should have mention that I've used Pit+ED1 numerous times in a effort to fix this. It goes through successfully; however, it doesn't actually wipe the partition and I've found old files in /system.
UPDATE:
Last thing I tried is manually wiping everything from /system (in CWMR + adb shell). Also, wiped everything I could find having anything to do with voodoo or EXT4 (just in case). After power off then back to recovery, I found I could umount /system. Created a new partition, formatted, then wacked the partition.
I just (successfully) ran ED1+pit from the Samsung Flashing Utility (which I have NOT tried using before) and I am now in the process of upgrading. Once I have root back, I'll go see if the fix for /system was permanent.
Now, i know there are a *few* places in the dev section that have ext4 optimizations. But these "optimizations" are for the conversion from ext3 to ext4 without having the reformat and everything.
I've been trying (unsuccessfully) to change some of the ext4 mount flags for better speed. My problem is, everything i do in making a CWM flashable with a ext4 optimize sh script errors out with a Status 0. it doesn't even run.
But this time, i though i'd try a few things using adb shell. I got some tune2fs stuff working, so i thought i'd run an fsck on it. There isn't any fsck located on the phone. So i copied over a fsck.ext4, ran it but then got this error (and it also left my rom unuseable, but luckily i had a nandroid):
Code:
***file system was modified*** invalid argument passed to ext2 library while rewriting block inode bitmaps
.
And when doing an ls of /sbin, there isn't anything in there related to ext4, let alone ext3. So i'm wondering, why is our phone supports ext4 partitions, but doesn't actually have anything to support them?
EDIT: running just the tune2fs seems to have worked, just need to test out any differences found first.
Is there any recovery or script for Desire S that can convert filesystem type to ext2?
Standard CWM 5.x does not have any convert option, 4EXT which I installed moment ago only converts to ext4 (pointless...).
You can use Linux commands in adb shell. Google the one you need.
Edit: this should do
If you do not have the binaries (e.g. commands) download the package from here, post 7, point 2. In the same post there is a description how to transfer them to the phone
why you what to downgrade to ext2
Who told ext4 is upgrade to ext2? Higher number does not mean better. Agree, ext4 originates from ext2, but these are just another file system types with different purpose.
And I think ext4 is an overkill because I just don't need journaling on... mobile phone.
I'm working in a method to increase SGY's internal /data partition. in my previous method I was using a modified kernel to load sdcard's ext paritition as /data. however, this kernel have bad issue with script manager. I've found the most easy easy way to increase our /data partition size in sgy. no need to install custom kernel, we'll need only a stock kernel with init.d support. with this new method we'll make a script '03data2sd' in init.d folder with these script inside
Code:
#!/system/bin/sh
umount /data
mount -t ext3 -o nosuid,nodev /dev/block/mmcblk0p2 /data
this method will solve my previous kernel incompatibility issue with script manager. however, the gps won't work with this method. the logcat file said that there was something wrong with gps_ril_BRCM. it said that 'RIL LCSAPI' isn't working. does anyone know how to fix it?