Ext4 fs?

Search This thread

rcgabriel

Senior Member
May 4, 2010
450
138
Just a quick thought - I was trying to figure out if I might get somewhat better filesystem performance out of ext4 rather than ext3 for the user data partition. As a first pass, I compiled a kernel with ext4 enabled, and tried to change my boot partition init.rc to mount /data as an ext4 partition rather than an ext3 - my understanding is they should be mount-compatible even without repartitioning.

The result of this was a bootloop. :( Had to reflash back to a working boot.img. Didn't do anything bad to my /data partition though.

Any ideas why this might be happening? Is there a way to grab dmesg from a boot looping kernel on Android?
 

jersacct

Senior Member
Nov 28, 2010
67
106
I've found the following procedures to be helpful in debugging custom kernels.

First, remove the fbcon.c patch in the kernel source (you can just edit the one line that gets modified and uncomment it):


Code:
nano drivers/video/console/fbcon.c

Search for "navy", then uncomment the line:

Code:
update_screen(vc);

Rebuild your kernel. Now you'll have the ability to get a framebuffer console, if your kernel command line arguments are correct. You have to supply custom kernel command line arguments when using mk-boot-img. I use the following when using mk-boot-image:

Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),273536K@96000K(system),153728K@370048K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)" -o boot.img

The important part there is changing the console parameter from the default ttyS0 to tty0.

I make separate boot images when debugging - one that executes a shell in the initial ramdisk, and one that doesn't. To get a shell in the initrd, which you'll want to do in this case to figure out your mount issue, is change the above mkbootimg --cmdline parameter:

Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "break=top mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),273536K@96000K(system),153728K@370048K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)" -o boot.img

Notice the "break=top". This will give you a command shell before anything in initrc has been executed. You could also use "break=bottom" or "break=init" to get you to different spots in initrc.

Hope that helps! Happy hacking!
 

rcgabriel

Senior Member
May 4, 2010
450
138
I've found the following procedures to be helpful in debugging custom kernels.

First, remove the fbcon.c patch in the kernel source (you can just edit the one line that gets modified and uncomment it):


Code:
nano drivers/video/console/fbcon.c

Search for "navy", then uncomment the line:

Code:
update_screen(vc);

Rebuild your kernel. Now you'll have the ability to get a framebuffer console, if your kernel command line arguments are correct. You have to supply custom kernel command line arguments when using mk-boot-img. I use the following when using mk-boot-image:

Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),273536K@96000K(system),153728K@370048K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)" -o boot.img

The important part there is changing the console parameter from the default ttyS0 to tty0.

I make separate boot images when debugging - one that executes a shell in the initial ramdisk, and one that doesn't. To get a shell in the initrd, which you'll want to do in this case to figure out your mount issue, is change the above mkbootimg --cmdline parameter:

Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "break=top mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),273536K@96000K(system),153728K@370048K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)" -o boot.img

Notice the "break=top". This will give you a command shell before anything in initrc has been executed. You could also use "break=bottom" or "break=init" to get you to different spots in initrc.

Hope that helps! Happy hacking!

Hey jersacct, so I've tried this (recompiled with your suggested patch, then made new boot image with the last set of params you mentioned) and I absolutely see the framebuffer scrolling by rapidly right after the Viewsonic Birds display. However, I never get the break into console - the FB scrolls by very quickly, then I get the GTabDevs boot image for about 2 seconds, then I boot loop again. :(

Any ideas? I have tried both the break=top and break=init variants of that mkbootimg command line with no success.

EDIT: I tried with a known-good ramdisk image too. The boot.img boots fine, but again I never get dropped to console.
 
Last edited:

rcgabriel

Senior Member
May 4, 2010
450
138
Hmm, I suspected the issue might be that the default config has a pesky setting called CONFIG_CMDLINE="" that could be force-overriding any command line passed to the kernel from the boot image. Tried again with that line commented out, and still didn't have any luck getting the break= command to do anything.

I could probably try forcing the command line from CONFIG_CMDLINE but not sure why that would be different from passing it in mkbootimg...

EDIT: nope, I tried that too. Doesn't make a difference. So I assume it's receiving the CMDLINE just fine. For some reason break=top isn't giving me a console. I also tried it with my USB keyboard already plugged in to see if that was making a difference with the input devices, and still no console. :(
 
Last edited:

rcgabriel

Senior Member
May 4, 2010
450
138
Still no luck on the debug console. At my wit's end on that. All I can say is that on a regular boot with ext3 mounting my /data partition I see that the partition is dirty and the first mount attempt fails. Second attempt seems to succeed. Says I need to fsck my data partition - which I'd do, but our busybox doesn't seem to support fsck. :(

Anybody know where I can find a busybox binary that properly supports fsck for ext2/3 and also has mkfs.ext4? I know the Archos guys seem to have one and that's an ARM v9 device so it should work, but I'm having trouble finding it (I even downloaded the "SDE" firmware from the Archos site).

I think the reason the ext4 driver is probably just that it's dirty, though I can't confirm that without the damned debug console.

If I can get an up-to-date busybox on here, I suspect this will just start working magically, without further ado. Ideas are appreciated, either on busybox binaries or on getting the initramdisk console stuff that jersacct posted to work.
 

jersacct

Senior Member
Nov 28, 2010
67
106
Still no luck on the debug console. At my wit's end on that. All I can say is that on a regular boot with ext3 mounting my /data partition I see that the partition is dirty and the first mount attempt fails. Second attempt seems to succeed. Says I need to fsck my data partition - which I'd do, but our busybox doesn't seem to support fsck. :(

Anybody know where I can find a busybox binary that properly supports fsck for ext2/3 and also has mkfs.ext4? I know the Archos guys seem to have one and that's an ARM v9 device so it should work, but I'm having trouble finding it (I even downloaded the "SDE" firmware from the Archos site).

I think the reason the ext4 driver is probably just that it's dirty, though I can't confirm that without the damned debug console.

If I can get an up-to-date busybox on here, I suspect this will just start working magically, without further ado. Ideas are appreciated, either on busybox binaries or on getting the initramdisk console stuff that jersacct posted to work.

You know, I didn't think to mention that I was using the Karmic ramdisk image - I bet our stock ramdisk image doesn't have breakpoints setup in initrc. You can grab a copy of a stock initrd image here:
http://www.retardedrobot.com/karmic-initrd-orig.gz

Then just use it instead of the stock ramdisk image when using mkbootimg. Please note, I hardcoded mine to get root to work off the SD card. I think this is an unmodified initrd, so it may work straight out of the box (and boot android if allowed). You might have problems with it though, and may need to unpack it, edit some scripts (for mounting root, etc) and repackage it.

Hope that helps.
 

rcgabriel

Senior Member
May 4, 2010
450
138
You know, I didn't think to mention that I was using the Karmic ramdisk image - I bet our stock ramdisk image doesn't have breakpoints setup in initrc. You can grab a copy of a stock initrd image here:
http://www.retardedrobot.com/karmic-initrd-orig.gz

Then just use it instead of the stock ramdisk image when using mkbootimg. Please note, I hardcoded mine to get root to work off the SD card. I think this is an unmodified initrd, so it may work straight out of the box (and boot android if allowed). You might have problems with it though, and may need to unpack it, edit some scripts (for mounting root, etc) and repackage it.

Hope that helps.

Ahh, this explains why it doesn't work. Thanks so much, I'll take a crack, but hopefully I can clean up my /data partition into a proper ext4 partition with busybox and get it mounting now. I'll see tomorrow, too tired tonight.
 

rcgabriel

Senior Member
May 4, 2010
450
138
Ba...ZING! Finally got ext4 driver working properly. Figured out what was causing the bootloops before, I think - or at least localized the issue.

Running an e2fsck and disabling inandop.sh seems to have done the trick. I think one of the checks in inandop.sh was triggering a reboot. My init.rd now successfully mounts /data as an ext4 partition, mount reports the partition as ext4.

What I need to do now is try to clean up inandop.sh so it properly uses the right binaries to set up the partition as a true ext4. Currently just mounting an ext3 partition with the ext4 driver.

So far no significant performance boost in Quadrant, it's within 50 points of where it was before. But I'm not done yet.
 

rob_z11

Senior Member
Ba...ZING! Finally got ext4 driver working properly. Figured out what was causing the bootloops before, I think - or at least localized the issue.

Running an e2fsck and disabling inandop.sh seems to have done the trick. I think one of the checks in inandop.sh was triggering a reboot. My init.rd now successfully mounts /data as an ext4 partition, mount reports the partition as ext4.

What I need to do now is try to clean up inandop.sh so it properly uses the right binaries to set up the partition as a true ext4. Currently just mounting an ext3 partition with the ext4 driver.

So far no significant performance boost in Quadrant, it's within 50 points of where it was before. But I'm not done yet.

will it incorporate in the future Vegan release? I know we have to do complete format, and goto ext4?

Will love if we can get ext4.
 

stanglx

Senior Member
Dec 11, 2010
268
42
Are you using internal or external (sd card) for the test? The internel storage is very very slow compared to most class 4 sd cards.


Ba...ZING! Finally got ext4 driver working properly. Figured out what was causing the bootloops before, I think - or at least localized the issue.

Running an e2fsck and disabling inandop.sh seems to have done the trick. I think one of the checks in inandop.sh was triggering a reboot. My init.rd now successfully mounts /data as an ext4 partition, mount reports the partition as ext4.

What I need to do now is try to clean up inandop.sh so it properly uses the right binaries to set up the partition as a true ext4. Currently just mounting an ext3 partition with the ext4 driver.

So far no significant performance boost in Quadrant, it's within 50 points of where it was before. But I'm not done yet.
 

rcgabriel

Senior Member
May 4, 2010
450
138
Are you using internal or external (sd card) for the test? The internel storage is very very slow compared to most class 4 sd cards.

Using internal SD card. I don't have an extra microSD handy here, just the one in my Nexus One, which is 16GB class 2 so probably too slow to be useful for that.

Still I'm fairly convinced that I should be able to get better results with the internal SD card.
 

stanglx

Senior Member
Dec 11, 2010
268
42

rcgabriel

Senior Member
May 4, 2010
450
138
Take a look.. See if your getting the same results with ext4..

Here is the output of a test:
http://xdaforums.com/showpost.php?p=10239762&postcount=2

As you can see a Class

I'll do more testing later, but right now I've managed to bootloop my G Tablet and I don't have my USB cable here, it's at the office (snow day today). I can boot to recovery but it seems like ClockworkMod recovery 0.8 doesn't want to mount my external MicroSD card from my N1 to copy over a working update.zip to re-flash.

So unless I find another USB cable lying around the apartment somewhere, my G Tablet is out of commission until Monday or until I hit the nearest Radio Shack this weekend. :)
 

rcgabriel

Senior Member
May 4, 2010
450
138
Status update: I am waiting on a class 6 SD card from Newegg so I can try more stuff out and perfect this without continually screwing up my internal SD card and having to repartition, reformat, etc.

In the meantime, I have tried adapting Chenglu's data2loop method to use an ext4 filesystem in the loop device files rather than an ext2 filesystem as he uses, using a kernel with ext4 enabled.

The good - I'm getting even higher Quadrant benchmarks than with the baseline data2loop. Up to around 3470, averaging around 3400 with a couple of runs. I was, with the same kernel and Chenglu's data2loop patch, getting in the 3200s to 3300s, so the difference seemed somewhat significant to me.

Unfortunately, it seems to puke out every time I reboot. The data must get screwed up somehow in the /data/ext4 files, and my G Tab goes schizo and won't even finish the bootup process - screen flickers from the "Vegan" logo during boot, and then screen shuts off. Have to hard shut-down then hard reboot to recovery and wipe data to get things working again.

The /misc/inandop.log file seems to report that data-to-loop was successfully enabled, so I'm not sure exactly why it's puking out in such epic fashion. Have to work more on this later.
 
Last edited:

stanglx

Senior Member
Dec 11, 2010
268
42
Most likely experiencing some corruption in the cache.... add the sync command to the mount and see if that helps stability using the loopback device.... Also when you create the file system are you using

mkfs.ext4 -O ^huge_file ....

I have read you need to turn off huge_file as it causes some issues (dont remember where I read it though)



Status update: I am waiting on a class 6 SD card from Newegg so I can try more stuff out and perfect this without continually screwing up my internal SD card and having to repartition, reformat, etc.

In the meantime, I have tried adapting Chenglu's data2loop method to use an ext4 filesystem in the loop device files rather than an ext2 filesystem as he uses, using a kernel with ext4 enabled.

The good - I'm getting even higher Quadrant benchmarks than with the baseline data2loop. Up to around 3470, averaging around 3400 with a couple of runs. I was, with the same kernel and Chenglu's data2loop patch, getting in the 3200s to 3300s, so the difference seemed somewhat significant to me.

Unfortunately, it seems to puke out every time I reboot. The data must get screwed up somehow in the /data/ext4 files, and my G Tab goes schizo and won't even finish the bootup process - screen flickers from the "Vegan" logo during boot, and then screen shuts off. Have to hard shut-down then hard reboot to recovery and wipe data to get things working again.

The /misc/inandop.log file seems to report that data-to-loop was successfully enabled, so I'm not sure exactly why it's puking out in such epic fashion. Have to work more on this later.
 

rcgabriel

Senior Member
May 4, 2010
450
138
So just to update this thread, I did get ext4 working stably on the /data partition. The trick is doing everything from recovery mode - making the ext4 filesystem via adb push and adb shell, then flashing an update.zip from recovery that packages a kernel that supports ext4 with a ramdisk/init.rc that mounts /data as ext4 and skips the inandop.sh step entirely since that was the source of bootloops (stock inandop.sh expects /data to be ext3 and pukes if it's not).

You can see my detailed instructions over here: http://xdaforums.com/showpost.php?p=10489732&postcount=23

The bad news is really no significant performance bump from ext4 in the standard 2gig partition. But I expect it to be stable as hell. :) Still need to experiment more with ways to speed things up (safely).
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    I've found the following procedures to be helpful in debugging custom kernels.

    First, remove the fbcon.c patch in the kernel source (you can just edit the one line that gets modified and uncomment it):


    Code:
    nano drivers/video/console/fbcon.c

    Search for "navy", then uncomment the line:

    Code:
    update_screen(vc);

    Rebuild your kernel. Now you'll have the ability to get a framebuffer console, if your kernel command line arguments are correct. You have to supply custom kernel command line arguments when using mk-boot-img. I use the following when using mk-boot-image:

    Code:
    mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),273536K@96000K(system),153728K@370048K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)" -o boot.img

    The important part there is changing the console parameter from the default ttyS0 to tty0.

    I make separate boot images when debugging - one that executes a shell in the initial ramdisk, and one that doesn't. To get a shell in the initrd, which you'll want to do in this case to figure out your mount issue, is change the above mkbootimg --cmdline parameter:

    Code:
    mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "break=top mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),273536K@96000K(system),153728K@370048K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)" -o boot.img

    Notice the "break=top". This will give you a command shell before anything in initrc has been executed. You could also use "break=bottom" or "break=init" to get you to different spots in initrc.

    Hope that helps! Happy hacking!