Develop Bugs

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

Exploring how to get Android to cleanly unmount /data

Several of us are exploring how to change an Android build so that it unmounts the /data partition cleanly when shutting down. This thread is dedicated to discussion of how to do that. Solutions may eventually appear here, but will work their way into the various build and/or kernel threads.

reserved
Watch this space for a summary of answers and solutions.

Roughly how it works today
The Shutdown thread stops applications, and then tells the Volume Manager to shutdown. After that, the Shutdown thread calls reboot() which calls _reboot() which turns off power.
I think the key is in Volume Manager.
Volume Manager's Java code works with the C++ application "vold".
Volume Manager gets a list of mounted filesystems from vold.
Vold returns a list that it manages, not the same as "df" or "mount" from the command line. That list (at least in Fresh Froyo) does not include /data or /cache.
Volume Manager then, for each filesystem in the list, tells vold to unmount the filesystem. Each filesystem has a timeout, and Volume Manager eventually either finds success or gives up.
The "vold" application can be controlled with a command-line executable called "vdc". Commands like : "vdc volume unmount /sdcard" or "vdc volume list", use the same syntax as Volume Manager uses to talk to vold.
Perhaps the answer to all of this is to get /data registered with vold at startup.
What I have tried, with great failure, is a terrible hack where I modified the implementation of reboot() to call system("/system/bin/rosysdata") before calling _reboot(). Then I created /system/bin/rosysdata to remount /system and /data as r/o. That worked for a couple of shutdowns, but after that caused extreme filesystem failure a few times. It was a bad hack anyway, so I have never committed that.

If we can get the /data filesystem mounted by vold instead of just mounting it in the bootup scripts, it should get unmounted at shutdown, since VolumeManager gets a list of mounted volumes from vold and unmounts each of them.
I am trying this but don't have much success yet.
Another idea is to get android to execute a shutdown script as it shuts down.

The old initrd create severl problems with mounting because there was several binding to the data partition.
Now there is only one /data mounted to the partition.
The old script files has the problem with the binding but now they should work.
I think that vold can't be used with data so we need to exec:
Code:
sync
mount -o remount,ro /data
in a shutdown script.

energy cut
what about when the system crashes and battery has to be removed?
anergy cut ...
What about use different partitions?
/system, /data and /cache as different partitions...
the highest activity of reading and writing happens in /cache. Am I right?
I'll change the nbh and sysinit.rc to meet this.

tiagoclc said:
what about when the system crashes and battery has to be removed?
anergy cut ...
What about use different partitions?
/system, /data and /cache as different partitions...
the highest activity of reading and writing happens in /cache. Am I right?
I'll change the nbh and sysinit.rc to meet this.
Click to expand...
Click to collapse
Isn't /cache a symlink to /data/tmpcache ? couldn't we redirect to /mnt/sdcard/cache ? (or anywhere else ?)

Due to these issues I can reboot normally only if I clear Dalvik cache. Maybe it could be automatic on boot lol

drvitorino said:
Due to these issues I can reboot normally only if I clear Dalvik cache. Maybe it could be automatic on boot lol
Click to expand...
Click to collapse
I second this or how about we manually enter mount -o remount, ro /data on terminal before turning it off?

ohohoh, apparently L1qu1d fixed my issue with the new kernel and the update from http://forum.xda-developers.com/showthread.php?t=848921
Unfortunately wi-fi and data connection is still not working with the update in my kaiser. But L1qu1d may be happy to know that his code inside the update has something that fix data corruption when turning off/on the device.

drvitorino said:
ohohoh, apparently L1qu1d fixed my issue with the new kernel and the update from http://forum.xda-developers.com/showthread.php?t=848921
Unfortunately wi-fi and data connection is still not working with the update in my kaiser. But L1qu1d may be happy to know that his code inside the update has something that fix data corruption when turning off/on the device.
Click to expand...
Click to collapse
In my test, some data corruption still exists (when lots of widgets and data partition close to full) but is easily corrected by clearing the dalvik-cache, but some apps are lost in the launcher. I still think that unmounting the data partition before turning off or reboot is the best way to prevent this.

n2rjt said:
The Shutdown thread stops applications, and then tells the Volume Manager to shutdown. After that, the Shutdown thread calls reboot() which calls _reboot() which turns off power.
I think the key is in Volume Manager.
Volume Manager's Java code works with the C++ application "vold".
Volume Manager gets a list of mounted filesystems from vold.
Vold returns a list that it manages, not the same as "df" or "mount" from the command line. That list (at least in Fresh Froyo) does not include /data or /cache.
Volume Manager then, for each filesystem in the list, tells vold to unmount the filesystem. Each filesystem has a timeout, and Volume Manager eventually either finds success or gives up.
The "vold" application can be controlled with a command-line executable called "vdc". Commands like : "vdc volume unmount /sdcard" or "vdc volume list", use the same syntax as Volume Manager uses to talk to vold.
Perhaps the answer to all of this is to get /data registered with vold at startup.
Click to expand...
Click to collapse
Since our data is installed in NAND, I don't think "vold" can mount Nand partition. Not too sure though.

clemsyn said:
Since our data is installed in NAND, I don't think "vold" can mount Nand partition. Not too sure though.
Click to expand...
Click to collapse
from: http://osdir.com/ml/android-porting/2010-06/msg00279.html
Vold doesn't mount Nand.
Mounting of Nand partitions is done in init.rc
mountd: mount all fs defined in /system/etc/mountd.conf if started,
receive commands through local socket to mount any fs. The source is
in device/system/bin/mountd.
-
Sreekanth
On Jun 24, 5:47 pm, "Dennis.Yxun" <[email protected]> wrote:
> HI Community:
> I'm using donut branch, and my system have two block devices, I want them
> all mounted
> 1) nand flash: /dev/block/sdb
> 2) MMC/SD card: /dev/block/mmcblk0
>
> Current, I successfully use vold mount the MMC/SD card
> (/dev/block/vold/179:0 -> /dev/block/mmcblk0)
>
> My question here is :
> Does vold support to mount the Nand Device too? like
> mount /dev/block/sdb to /sdcard/nand
> mount /dev/block/mmcblk0 to /sdcard/mmc
>
> Dennis
is this true?

[HOWTO] Convert ext4 partitions to No-Journaling mode

WARNING: This procedure is risky and may result in loss of data.
This is a follow up to findings made in this thread: http://forum.xda-developers.com/showthread.php?t=819580
Many people have been asking for an ext2 lagfix. You can get something similar but (arguably) better: ext4 with no journaling. Ext4 no-journal performs as fast or faster than ext2 because of performance improvements made in ext4.
Quadrant comparison for ext4 /data-only lagfix:
ext4 scores about 1500, ext4 no-journal scores about 1650.
This should work with existing kernels that support ext4 lagfixes. It's tested on a ULFK kernel (SpeedMod).
WARNING: Turning off journaling makes your data more susceptible to getting corrupted, although the risk is small.
Disclaimer: No promises that this will work for you, or that it won't corrupt your data. Try this at your own risk.
Step 0: You start off by applying an ext4 lagfix. If you are already using an ext4 lagfix, you can skip this step.
For ULFK kernels, this is either:
- "Voodoo" ext4 /data
- No-RFS advanced ext4
After the lagfix has been successfully applied and your phone is up and running properly, then you can proceed to convert the ext4 partitions.
Step 1: Make a backup of your data, using CWM (recommended). If anything goes wrong, you can restore the backup later.
Step 2: Download the tune2fs file attached to this post (works for FROYO roms only), and copy it to /data as /data/tune2fs:
adb push tune2fs /sdcard/
adb shell
# su
# cp /sdcard/tune2fs /data/
Procedure if your kernel has ro.debuggable enabled:
Step 3: If your kernel has ro.debuggable enabled, then boot your phone into recovery mode. Then run adb in root mode:
adb root
(wait for adbd to restart)
adb shell
Copy tune2fs to the /tmp folder.
# cp /data/tune2fs /tmp/
If you don't have ro.debuggable enabled, "adb root" will give you an error. Go to Step 3A in the next section.
Step 4: Now in ADB shell, find out which partitions are ext4:
# mount | grep ext4
mount | grep ext4
/dev/block/mmcblk0p2 on /data type ext4 (rw,noatime,barrier=0,data=writeback,noauto_da_alloc)
/dev/block/stl10 on /dbdata type ext4 (rw,noatime,barrier=0,data=writeback,noauto_da_alloc)
/dev/block/stl11 on /cache type ext4 (rw,noatime,barrier=0,data=writeback,noauto_da_alloc)
In this example, the 3 partitions are:
/dev/block/mmcblk0p2 (/data)
/dev/block/stl10 (/dbdata)
/dev/block/stl11 (/cache)
Repeat Steps 5 to 9 for every partition you want to remove the journal from.
The next steps show the procedure for /dev/block/mmcblk0p2 (/data).
Step 5: Unmount the partition:
umount partition_mount_point
for example:
# umount /data
Step 6: Check if there is a journal:
# /tmp/tune2fs -l /dev/block/mmcblk0p2 | grep features
You should see something like this:
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
You should see "has_journal" in the features. It means this partition has a journal.
Step 7: Fsck the partition:
# e2fsck -f /dev/block/mmcblk0p2
Step 8: Remove the journal:
# /tmp/tune2fs -O ^has_journal /dev/block/mmcblk0p2
(this is a capital "O"!)
Step 9: Check if the journal was removed:
# /tmp/tune2fs -l /dev/block/mmcblk0p2 | grep features
You should see something like this:
Filesystem features: ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
You should see "has_journal" is NOT there.
Done for this partition.
Step 10: After you've remove the journal from all the partitions you wanted to, shutdown the phone by pressing the power button.
DONE. You only need to do this procedure once and it'll "stick" until the next time you re-format the partition.
--------------------------------------------------
Procedure if you don't have ro.debuggable enabled:
Step 3A: If you kernel does not have ro.debuggable enabled, then you can try doing this using normal adb with su while the phone is running. But this is much more risky.
To lower the risk, do this right after booting, wait for the Media Scan to complete.
adb shell
# su
Step 4A: Now in ADB shell, find out which partitions are ext4:
# mount | grep ext4
mount | grep ext4
/dev/block/mmcblk0p2 on /data type ext4 (rw,noatime,barrier=0,data=writeback,noauto_da_alloc)
/dev/block/stl10 on /dbdata type ext4 (rw,noatime,barrier=0,data=writeback,noauto_da_alloc)
/dev/block/stl11 on /cache type ext4 (rw,noatime,barrier=0,data=writeback,noauto_da_alloc)
In this example, the 3 partitions are:
/dev/block/mmcblk0p2 (/data)
/dev/block/stl10 (/dbdata)
/dev/block/stl11 (/cache)
Repeat Steps 5A to 8A for every partition you want to remove the journal from.
The next steps show the procedure for /dev/block/mmcblk0p2 (/data).
Step 5A: Check if there is a journal:
# /data/tune2fs -l /dev/block/mmcblk0p2 | grep features
You should see something like this:
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
You should see "has_journal" in the features. It means this partition has a journal.
Step 6A: Fsck the partition:
# e2fsck -f /dev/block/mmcblk0p2
WARNING!!! Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.
Do you really want to continue (y/n)?
Answer yes.
Step 7A: Remove the journal:
# /data/tune2fs -O ^has_journal /dev/block/mmcblk0p2
(this is a capital "O"!)
Step 8A: Check if the journal was removed:
# /data/tune2fs -l /dev/block/mmcblk0p2 | grep features
You should see something like this:
Filesystem features: ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
You should see "has_journal" is NOT there.
Done for this partition.
Step 9A: After you've remove the journal from all the partitions you wanted to, shutdown the phone by pressing the power button. Reboot the phone and hope everything works.
DONE. You only need to do this procedure once and it'll "stick" until the next time you re-format the partition.

Nice one!
Going to try this tomorrow!
__________________________
Device: GT-I9000 16GB
Rom: Doc's V8 Nude&Raw v3
Kernel: Hardcore's Speedmod K9A - 500 Hz
Modem: JPP
Lagfix: No RFS, ext4-ext2, no binds
Tweaks: I/O Sched, Kernel VM Management, Kernel sched

Please ignore.

danzgrace said:
http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#364
Data Mode
=========
There are 3 different data modes:
* writeback mode
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.
* ordered mode
In data=ordered mode, ext4 only officially journals metadata, but it logically groups metadata information related to data changes with the data blocks into a single unit called a transaction. When it's time to write the new metadata out to disk, the associated data blocks are written first. In general,
this mode performs slightly slower than writeback but significantly faster than journal mode.
* journal mode
data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state. This mode is the slowest except when data needs to be read from and written to disk at the same time where it outperforms all others modes. Currently ext4 does not have delayed allocation support if this data journalling mode is selected.
Click to expand...
Click to collapse
Applying writeback mode is the best option.

danzgrace said:
Applying writeback mode is the best option.
Click to expand...
Click to collapse
Hi danzgrace. Those options you quoted are for journaled modes. data=writeback is still a journaled mode.
This procedure is for non-journaled mode (none of the above). Its faster than all of the above because there is *no* journal.

hardcore said:
Hi danzgrace. Those options you quoted are for journaled modes. data=writeback is still a journaled mode.
This procedure is for non-journaled mode (none of the above). Its faster than all of the above because there is *no* journal.
Click to expand...
Click to collapse
Yes. Just stumbled upon lots of docu about ext4 and you are right about the performance gain when there's no journal involve but kind of risky.
https://ext4.wiki.kernel.org/index.php/Ext4_Howto#.22No_Journaling.22_mode

danzgrace said:
Yes. Just stumbled upon lots of docu about ext4 and you are right about the performance gain when there's no journal involve but kind of risky.
https://ext4.wiki.kernel.org/index.php/Ext4_Howto#.22No_Journaling.22_mode
Click to expand...
Click to collapse
It should be no more risky than ext2. Been using it for a few days now and so far so good.

danzgrace said:
Yes. Just stumbled upon lots of docu about ext4 and you are right about the performance gain when there's no journal involve but kind of risky.
https://ext4.wiki.kernel.org/index.php/Ext4_Howto#.22No_Journaling.22_mode
Click to expand...
Click to collapse
But its not much more risky because writeback journal does not prevent data loss - it just removes the need of a filecheck after unclean unmounting. Data still can be lost or?
Sent from my GT-I9000 using XDA App

Can you implement this tweak in speedmod kernel?
Sent from my GT-I9000 using XDA App

IMO, keeping the journal, with the default data=ordered option, is a good safety vs. speed compromise.
However, have you tried fiddling with the commit= mount option? The default commit interval is 5 s - this could be what's detrimental to battery life (a wake every 5 seconds). Maybe upping this to 60, or even more, seconds? I myself wouldn't care if it were 5 minutes on a phone, but upping it to one minute should already show a significant battery life increase.

corgar said:
Can you implement this tweak in speedmod kernel?
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Not that easy because I have to modify the recovery executable. Maybe at a later stage.

AnnihilatorSC said:
IMO, keeping the journal, with the default data=ordered option, is a good safety vs. speed compromise.
However, have you tried fiddling with the commit= mount option? The default commit interval is 5 s - this could be what's detrimental to battery life (a wake every 5 seconds). Maybe upping this to 60, or even more, seconds?
Click to expand...
Click to collapse
I'm not sure if this has any effect when there's no journal. But I guess it's worth a shot.

I hope there is a way to do this in a script and apply by update.zip in recovery. Please tell me this can be done...
In general use, just how much faster does this feel? I'm asking because regular ext4 does not feel much faster in general use than RFS using speedmod. Back when I was using JM8 + OCLF, k-9 Email was so much faster.

hardcore said:
I'm not sure if this has any effect when there's no journal. But I guess it's worth a shot.
Click to expand...
Click to collapse
It doesn't. But I aim to hang on to the journal.
You could try releasing a SpeedMod revision which mounts all ext4 fs's with commit=60. If you do, i'll be sure to report the battery life - the effect should already be obvious to me after a night on battery (I currently lose about 20% battery overnight - no-rfs advanced ext4, w/ defaults).

hardcore said:
I'm not sure if this has any effect when there's no journal. But I guess it's worth a shot.
Click to expand...
Click to collapse
I guess commit=60 or more and journal_async_commit, can save us a lot of battery power.

you can change the commit options by remounting the disk.. in adb or terminal with root..
mount -oremount,data=writeback,journal_async_commit,... /dev/block/... /data (for example)
you will lose it at phone reboot, too - but good for testing

bilboa1 said:
you can change the commit options by remounting the disk.. in adb or terminal with root..
mount -oremount,data=writeback,journal_async_commit,... /dev/block/... /data (for example)
you will lose it at phone reboot, too - but good for testing
Click to expand...
Click to collapse
not unless it was on your playlogos hack.

danzgrace said:
journal_async_commit, can save us a lot of battery power.
Click to expand...
Click to collapse
I sincerely doubt journal_async_commit would bring about better power utilization. Maybe a slight performance increase, but nothing significant. Personally, I wouldn't enable that option.

danzgrace said:
not unless it was on your playlogos hack.
Click to expand...
Click to collapse
SpeedMod and ULFK supports init scripts, without the playlogos hack.
Just name the script E_something.sh and place it in /system/etc/init.d/
For example /system/etc/init.d/E_startup.sh

hardcore said:
SpeedMod and ULFK supports init scripts, without the playlogos hack.
Just name the script E_something.sh and place it in /system/etc/init.d/
For example /system/etc/init.d/E_startup.sh
Click to expand...
Click to collapse
Thanks for the info. imho. I feel more safe putting the script on /data partition so if it fails I just factory reset rather than putting it on /system dir.

how can i launch e2fsck in twrp.

i need to check my nand memory to see if there is any demaged sector in it (im experiencing a lot of freezing with custm and stock roms, and i think it may be related to that).. i found that i can do that with e2fsck from the terminal, /system and /data need to be unmounted (it seems those are unmounted by default in TWRP), but i dont know how to go into the terminal in TWRP, in advanced options there is an option that say terminal but when i go there looks more like a file manager... im kinda noob in all this.. plz help!

adb shell
Sent from my i9250

[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 :/