Related
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
Rather than making a loopback filesystem, I've been trying to reformat the data partition as ext4, but haven't been able get past the galaxy "S" screen yet (the big S on boot). Here's what I did
* Compile a kernel with ext4 and modified init.rc to mount /data as ext4.
* Reboot into recovery and format /dev/block/mmcblk0p2 as ext4.
* Reboot into download and flash the custom kernel.
It was stuck at "S" for a while, then the screen went dark, and the only thing I could do was to pull out the battery. Then I went into recovery mode and found the partition was trashed, i.e. I couldn't mount it as ext4 again. I had to format it back to rfs and restore the stock kernel to get it to boot. I have to believe that there's something other than init.rc that assumes data partition to be in a certain format. Has anyone had success on a similar task?
BTW, the same process DID work for /dbdata, but I see no visible improvement in Quadrant score...
I has a similar thing occur on my first attempt with nilfs2. Did you remove anything that would attempt to mount as rfs? I think the rfs driver will claim pretty much anything that might be rfs, so if your format left the backup FAT intact, that might be your problem. By the way, the nilfs2+user_init kernel I posted in the mimocan fix thread does support ext4 as well, and allows you to customize the mount without rebuilding your kernel.
Sent from my SAMSUNG-SGH-I897 using XDA App
Does anyone know if the Behold II supports ext4 partitions? I know that BH_Man's roms support ext3 (which I currently use for apps2sd). Nu11u5 came out with a rooted kernel based on the 1.6 OTA update; however, it doesn't support apps2sd. I was thinking of upgrading my ext3 apps2sd partition to ext4 but I wanted to make sure that it will work first. I tried contacting BH_Man, but he hasn't responded yet.
Since no one has responded, I thought I would add what I found out about ext4 support in the Behold II [BH2]. According to the source code, It seems that the BH2's kernel does indeed have support for ext4; however, I was unable to verify that Samsung actually compiled their kernel with ext4 support.
Back in the old day, before Cyanogen and Amon_Ra's recovery, to upgrade an ext3 partition to ext4, this was all that was needed:
Code:
tune2fs -O extents,uninit_bg,dir_index /dev/block/mmcblk0p2
e2fsck -fpDC0 /dev/block/mmcblk0p2
When I ran those commands in recovery mode via adb, tune2fs refused to run because of a missing mtab file (meaning tune2fs couldn't verify that mmcblk0p2 was mounted or not). I could be that I needed to use a newer version of tune2fs (but I'm too lazy to compile it myself). Whatever I tried, tune2fs wouldn't run. I actually had to use Acronis Disk Director to upgrade from ext2 to ext3 as I ran into the same problem before btw. I decided to give up and just use ext3 for app2sd. It works well and the slow down isn't really noticeable. Plus I like the added bonus of the journal.
The moral of the story: When buying a phone, make sure there is an actively developed ROM for it (like Cyanogenmod). Otherwise, forget about hacking it.
While messing around with ext2 and data2ext i noticed that android doesn't umount the sd-ext partition (Vold process unmounts the fat partition just fine as it can be seen with logcat). Also cyanogen states the same in this posting (Im wasn't sure on this but i don't doubt him EDIT: i doubt him now ... ).
I wonder now why the recommended solution for file corruption issues is using ext3/4 (wich slows things down due to the journal and reduces the lifetime of flashdrives due to limited r/w cycles) instead of just make a shutdown script wich unmounts the ext partition? (About lifetime: I think 10.000-100.000 r/w cycles is a rather high value and lifetime is only a theoretical and not a practical issue - but im not sure on this)
Since i'm not really expirenced in scripting on either linux or android i wanted to ask if a script in "init.d/rc0.d" (+"init.d/rc6.d" for reboot) would be possible? I could write one but i don't know if this would be executed and i actually don't know how i could check if it works (i think logcat would be shutdown before this is done).
Edit: At least if rc0.d scripts are run BEFORE logcat stops it doesn't work. Logcat log is empty if i "grep test" an "echo "test"" script.
Need help. Someone ...
melethron said:
While messing around with ext2 and data2ext i noticed that android doesn't umount the sd-ext partition (Vold process unmounts the fat partition just fine as it can be seen with logcat). Also cyanogen states the same in this posting (Im wasn't sure on this but i don't doubt him ).
I wonder now why the recommended solution for file corruption issues is using ext3/4 (wich slows things down due to the journal and reduces the lifetime of flashdrives due to limited r/w cycles) instead of just make a shutdown script wich unmounts the ext partition? (About lifetime: I think 10.000-100.000 r/w cycles is a rather high value and lifetime is only a theoretical and not a practical issue - but im not sure on this)
Since i'm not really expirenced in scripting on either linux or android i wanted to ask if a script in "init.d/rc0.d" (+"init.d/rc6.d" for reboot) would be possible? I could write one but i don't know if this would be executed and i actually don't know how i could check if it works (i think logcat would be shutdown before this is done).
Click to expand...
Click to collapse
Does /system/bin/shutdown get called to turn off the phone?
Logcat looks like its the last thing to stop
coutts99 said:
Does /system/bin/shutdown get called to turn off the phone?
Logcat looks like its the last thing to stop
Click to expand...
Click to collapse
Code:
adb logcat | grep /system/bin/shutdown > ~/shutdowntest.log
Empty file
Although the file is present in ROM's so maybe it IS called after logcat stops. But i don't know if it's added to Custom ROMs and if it's also present in RUU's.
If it's not called do you see any possibility to use "Vold" process? Cause it does the unmounting:
Code:
I/Vold ( 145): /mnt/secure/staging/.android_secure sucessfully unmounted
I/Vold ( 145): /mnt/secure/asec sucessfully unmounted
I/Vold ( 145): /mnt/secure/staging sucessfully unmounted
I/Vold ( 145): /mnt/sdcard unmounted sucessfully
D/Vold ( 145): Volume sdcard state changing 5 (Unmounting) -> 1 (Idle-Unmounted)
melethron said:
Code:
adb logcat | grep /system/bin/shutdown > ~/shutdowntest.log
Empty file
Although the file is present in ROM's so maybe it IS called after logcat stops. But i don't know if it's added to Custom ROMs and if it's also present in RUU's.
If it's not called do you see any possibility to use "Vold" process? Cause it does the unmounting:
Code:
I/Vold ( 145): /mnt/secure/staging/.android_secure sucessfully unmounted
I/Vold ( 145): /mnt/secure/asec sucessfully unmounted
I/Vold ( 145): /mnt/secure/staging sucessfully unmounted
I/Vold ( 145): /mnt/sdcard unmounted sucessfully
D/Vold ( 145): Volume sdcard state changing 5 (Unmounting) -> 1 (Idle-Unmounted)
Click to expand...
Click to collapse
hmm, interesting. Maybe have to poke through the source and see what is called to shutdown the phone.
Sent from my HTC Desire using XDA App
coutts99 said:
hmm, interesting. Maybe have to poke through the source and see what is called to shutdown the phone.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
I think this would be a major improvement. Since journaling is actually bad for sd's. Im not sure on this, but the journal is in some specific area on the filesystem. If this is the case I'm not sure if algorithms used to distribute r/w on flash drives will help if the journal gets overwritten (as i understand it so far the r/w is distributet over FREE space but not if something gets overwriten). If this is the case the part of the SD with the journal will be stressed heavy.
I've been playing around with data2sd with ext2 for a few weeks now.
I might be wrong but I think that the system is unmounting cleanly /data (and not /dev/block/mtdblock5) because I always have a clean e2fsck log after rebooting the phone.
So basically if you mount something under the /data mountpoint, it won't be cleanly unmounted and you'll end-up with corrupted FS. That what happens for A2SD because /data is still /dev/block/mtdblock5. But if you mount straight over /data, like I do with DATA2SD, the system unmounts /data on shutdown, witch is now your ext partition (whether your ext partition or a file on ext partition mounted via a loop device) and your FS is not corrupted. In that case you don't need journaling and can stick with ext2.
sibere said:
I've been playing around with data2sd with ext2 for a few weeks now.
I might be wrong but I think that the system in unmounting cleanly /data (and not /dev/block/mtdblock5) because I always have a clean e2fsck log after rebooting the phone.
So basically if you mount something under the /data mountpoint, it won't be cleanly unmounted and you'll end-up with corrupted FS. That what happens for A2SD because /data is still /dev/block/mtdblock5. But if you mount straight over /data, like I do with DATA2SD, the system unmounts /data on shutdown, witch is now your ext partition (whether your ext partition or a file on ext partition mounted via a loop device) and your FS is not corrupted. In that case you don't need journaling and can stick with ext2.
Click to expand...
Click to collapse
Im pretty sure for 3 reasons that it doesnt unmount data:
1. Android unmounts "/sdcard" as it can be seen in logcat while other stuff isn't unmounted. It may be still that the other unmount stuff is not not by the "Vold" process. Sdcard needs to be able to get unmounted when the phone is plugged to usb.
2. I also did quite a lot testing with sd-ext directly mounted to /data and i did get quite a lot corruption. But it is situation depended. If my phone was "idle" i didn't get corruption (1 time in 20 reboots) with no corruption. Then to make absolutly sure that it works i shut it down right after it boots up. There is many stuff running then wich means there is a much higher chance that something is still written while it shutdowns. Doing this i had corruption every 3rd reboot.
3. And this is the most important reason why you didn't get corruption but i did : You use sync as a mount option so you there is no need to unmount it ^^ !!!!
Sync is not an option for me for some reason:
-No cache will slowdown write on small files heavily
-Without cache every other process has to wait if some writing is done (lags).
-Much more wear for the sd since small files aren't cached
Using ext2 with sync isn't an option for me. Either i get ext2 with a proper unmount to work or i'll use Ext4 with an "ordered" journal then (or maybe i give a s*** about data2ext then).
melethron said:
Im pretty sure for 3 reasons that it doesnt unmount data:
1. Android unmounts "/sdcard" as it can be seen in logcat while other stuff isn't unmounted. It may be still that the other unmount stuff is not not by the "Vold" process. Sdcard needs to be able to get unmounted when the phone is plugged to usb.
2. I also did quite a lot testing with sd-ext directly mounted to /data and i did get quite a lot corruption. But it is situation depended. If my phone was "idle" i didn't get corruption (1 time in 20 reboots) with no corruption. Then to make absolutly sure that it works i shut it down right after it boots up. There is many stuff running then wich means there is a much higher chance that something is still written while it shutdowns. Doing this i had corruption every 3rd reboot.
3. And this is the most important reason why you didn't get corruption but i did : You use sync as a mount option so you there is no need to unmount it ^^ !!!!
Sync is not an option for me for some reason:
-No cache will slowdown write on small files heavily
-Without cache every other process has to wait if some writing is done (lags).
-Much more wear for the sd since small files aren't cached
Using ext2 with sync isn't an option for me. Either i get ext2 with a proper unmount to work or i'll use Ext4 with an "ordered" journal then (or maybe i give a s*** about data2ext then).
Click to expand...
Click to collapse
To me, the main purpose with data2Sd was to get more storage with at least the same amount of performances than the original NAND. I found that, on top of the extra space I have now, I also have a very good performance, roughly the same as NAND on small files and a much better one on bigger files. And I'm not thinking about quadrant score here
Talking about the unmount, if I run an e2fsck -n on the ext2 file while it's in use by the system, I have a report of a few errors (like deleted inode with nodtime, or wrong count of free blocks) But if I shut down the phone and turn in on again, the e2fsck I run at boot reports no errors at all. I might be wrong but my guess is that there is a clean umount done at some stage...
What I am going to do is an other test. You know that when an ext2 partition is not umounted properly, a flag is activated and this ext2 partition must be checked, regardless of the number of mounts done before running a check. This flag can be check by running a tune2fs -l on the partition before mounting it. It is reported as well by the system that the partition hasn't been unmounted properly when you try to mount it and that it should be checked .
So If i turn off my phone, restart in recovery mode, run a tune2fs -l on the ext2 file or mount it manually, I should be able to see if the partition has been unmounted by the system or not before the actual reboot.
I'll report the results and let you know if I'm wrong
OK
I've just turned off my phone. rebooted in recovery, mounted the 2nd FAT32 partition and run a tune2fs -l ext2 (that's the name of my ext2 file mounted via a loop device over /data)
Here is the result:
Code:
tune2fs 1.40.8 (13-Mar-2008)
Filesystem volume name: userdata
Last mounted on: /data
Filesystem UUID: 296f98d0-21e8-48b6-82ac-6c94c4edf28d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr dir_index filetype sparse_super
Filesystem flags: unsigned_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 60800
Block count: 243056
Reserved block count: 0
Free blocks: 168874
Free inodes: 57516
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 7600
Inode blocks per group: 475
Filesystem created: Tue Dec 7 15:00:51 2010
Last mount time: Thu Dec 9 17:40:16 2010
Last write time: Thu Dec 9 21:16:43 2010
Mount count: 1
Maximum mount count: 21
Last checked: Thu Dec 9 17:40:10 2010
Check interval: 15552000 (6 months)
Next check after: Tue Jun 7 17:40:10 2011
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Default directory hash: half_md4
Directory Hash Seed: 8ff9238f-aef7-48a7-85e1-7d2d45b9e809
You can see that it's reporting that the system is clean. If the ext2 partition wasn't cleanly unmounted by the system at shutdown, it would never report as being clean.
Obviously, if I check the state now that, after booting to android, the FS is mounted over /data, it is reported as being unclean.
It's reporting 1 as mount count because I'm forcing an fsck on boot anyway.
This doesn't mean that I will never get errors tho. I even have some errors from time to time when I reboot my linux home server
melethron said:
-No cache will slowdown write on small files heavily
-Without cache every other process has to wait if some writing is done (lags).
-Much more wear for the sd since small files aren't cached
Using ext2 with sync isn't an option for me. Either i get ext2 with a proper unmount to work or i'll use Ext4 with an "ordered" journal then (or maybe i give a s*** about data2ext then).
Click to expand...
Click to collapse
Remember that there is no writeback cache (AFAIK) with YAFFS2
But I should try with sync off and see if the system is still "clean" after a shutdown. If the systems unmounts ext2 properly, then the cache should be flushed by the system before unmounting the filesystem.
sibere said:
OK
I've just turned off my phone. rebooted in recovery, mounted the 2nd FAT32 partition and run a tune2fs -l ext2 (that's the name of my ext2 file mounted via a loop device over /data)
You can see that it's reporting that the system is clean. If the ext2 partition wasn't cleanly unmounted by the system at shutdown, it would never report as being clean.
Obviously, if I check the state now that, after booting to android, the FS is mounted over /data, it is reported as being unclean.
It's reporting 1 as mount count because I'm forcing an fsck on boot anyway.
This doesn't mean that I will never get errors tho. I even have some errors from time to time when I reboot my linux home server
Click to expand...
Click to collapse
You are right about the "clean" flag being set while unmounted. But you forgot one thing. The "clean" flag must be cleared when the partition is mounted. You should check if it as also reported while it IS mounted .... if so mount doesn't write proberly to the superblock. I would do this myself but im on ext4 and afaik it isn't cleared on mount then. For me this far it shows also "clean" when it is mounted.
My guess that mount doesn't write the superblock proberly is also supported by the fact that your and my mount count both shows 1. This could be a coincidince (chance for this is 0,147928994083 %) but could also support my assumption.
So check again while you mounted your system.
EDIT: I completly agree with you that data2ext is about space. Considering speed i also expirienced that reading larger amounts of data from data/data is faster with data2ext. But i also expirienced some slowdown sometimes on ext 4. It was better on ext2 and with that im really fine.
Remount done: Mount count still 1. I bet you will also get clean when you mount your ext.
melethron said:
Since i'm not really expirenced in scripting on either linux or android i wanted to ask if a script in "init.d/rc0.d" (+"init.d/rc6.d" for reboot) would be possible? I could write one but i don't know if this would be executed and i actually don't know how i could check if it works (i think logcat would be shutdown before this is done).
Edit: At least if rc0.d scripts are run BEFORE logcat stops it doesn't work. Logcat log is empty if i "grep test" an "echo "test"" script.
Need help. Someone ...
Click to expand...
Click to collapse
i think that won't work with rc.0 as init.d script execution is initiated in
init.rc only for "before booting", its not as a "normal" linux init system
# Execute files in /etc/init.d before booting
service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
disabled
oneshot
i wonder if a shutdown.rc could be populated, there is a shutdown.bravo.rc but its empty
for init-handling, in the kernel source its in system/core/init
but im not fit with c/c++ to look into
maybe the init binary would have to be modified by a kernel dev to enable shutdown.rc / also possible that htc has motified it to not to be used.
woti23 said:
i think that won't work with rc.0 as init.d script execution is initiated in
init.rc only for "before booting", its not as a "normal" linux init system
# Execute files in /etc/init.d before booting
service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
disabled
oneshot
i wonder if a shutdown.rc could be populated, there is a shutdown.bravo.rc but its empty
for init-handling, in the kernel source its in system/core/init
but im not fit with c/c++ to look into
maybe the init binary would have to be modified by a kernel dev to enable shutdown.rc / also possible that htc has motified it to not to be used.
Click to expand...
Click to collapse
This would have been to easy ....
Well maybe some Kernel Dev will look into this.... coutts, sibere, anyone ... can you help ?
Btw: i still wonder why /system/bin/shutdown is present in ROMs if it's not used ....
melethron said:
This would have been to easy ....
Well maybe some Kernel Dev will look into this.... coutts, sibere, anyone ... can you help ?
Btw: i still wonder why /system/bin/shutdown is present in ROMs if it's not used ....
Click to expand...
Click to collapse
this works for the script that should be executed part
/system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/shutdown.d
runs every script which is in /system/etc/shutdown.d
if you create /system/etc/shutdown.d before
and put one or more executable script/s that do something in
melethron said:
You are right about the "clean" flag being set while unmounted. But you forgot one thing. The "clean" flag must be cleared when the partition is mounted. You should check if it as also reported while it IS mounted .... if so mount doesn't write proberly to the superblock. I would do this myself but im on ext4 and afaik it isn't cleared on mount then. For me this far it shows also "clean" when it is mounted.
My guess that mount doesn't write the superblock proberly is also supported by the fact that your and my mount count both shows 1. This could be a coincidince (chance for this is 0,147928994083 %) but could also support my assumption.
So check again while you mounted your system.
EDIT: I completly agree with you that data2ext is about space. Considering speed i also expirienced that reading larger amounts of data from data/data is faster with data2ext. But i also expirienced some slowdown sometimes on ext 4. It was better on ext2 and with that im really fine.
Remount done: Mount count still 1. I bet you will also get clean when you mount your ext.
Click to expand...
Click to collapse
Sorry mate, but, like I wrote in my previous post, it shows unclean when mounted.
Sent from my HTC Desire using XDA App
sibere said:
Sorry mate, but, like I wrote in my previous post, it shows unclean when mounted.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
ROFL! I should learn to read proberly:
Obviously, if I check the state now that, after booting to android, the FS is mounted over /data, it is reported as being unclean.
Click to expand...
Click to collapse
Well thats actually good news thanks for helping me reading. ^^
Well so this isn't a problem. Now its time for ext4 (no loop) without journal mounted to data. About the loopdevice: you might wanna read what ownhere has to say about loop.
melethron said:
If it's not called do you see any possibility to use "Vold" process? Cause it does the unmounting:
Code:
I/Vold ( 145): /mnt/secure/staging/.android_secure sucessfully unmounted
I/Vold ( 145): /mnt/secure/asec sucessfully unmounted
I/Vold ( 145): /mnt/secure/staging sucessfully unmounted
I/Vold ( 145): /mnt/sdcard unmounted sucessfully
D/Vold ( 145): Volume sdcard state changing 5 (Unmounting) -> 1 (Idle-Unmounted)
Click to expand...
Click to collapse
http://android.git.kernel.org/?p=pl...2af4c72427ad069245d0aa572;hb=refs/heads/froyo
Some interesting stuff in this code here
coutts99 said:
http://android.git.kernel.org/?p=pl...2af4c72427ad069245d0aa572;hb=refs/heads/froyo
Some interesting stuff in this code here
Click to expand...
Click to collapse
i'm running this now on btrfs partition
/dev/block/mmcblk0p6** on /system/sd type btrfs (rw,relatime,ssd,noacl)
/dev/block/mmcblk0p6 5.2G 1.3G 3.9G 26% /system/sd
tmpfs 85.8M 24.0M 61.8M 28% /cache
a2sd btrfs *
d2sd btrfs *
dalvik-cache in /data mtd
cache in ram 90M
* without loop mounted img filesystem
** logical partition on extented partition
woti23 said:
i'm running this now on btrfs partition
/dev/block/mmcblk0p6** on /system/sd type btrfs (rw,relatime,ssd,noacl)
/dev/block/mmcblk0p6 5.2G 1.3G 3.9G 26% /system/sd
tmpfs 85.8M 24.0M 61.8M 28% /cache
a2sd btrfs *
d2sd btrfs *
dalvik-cache in /data mtd
cache in ram 90M
* without loop mounted img filesystem
** logical partition on extented partition
Click to expand...
Click to collapse
Running what now?
conventional (not froyo app2sd) a2sd + data2sd both on btrfs without loopmounted filesystem files
/data/dalvik-cache left in nand
/cache tmpfs in RAM
btrfs instead of ext4
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.