yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] SlimJ87D:
Guys, please be aware that this method is not stable.

There are possibilities of your mic input from both the phone and bluetooth won't come otu right. You will sound weird or not be heard at all because of static.

There is also a lag when turning your phone to the unlock speed. This is due to the SDCard powering on and taking it's sweet time. The lag can last to 3 seconds and for some others 5 seconds.

I would highly advise for you guys to wait for a more stable version to come out unless if you are testing to help our developers out.
[Captivate Android Development] Fortune090:
+1

I can attest to all of these errors...
[Captivate Android Development] ranova:
as with those bugs listed above, has anyone else tested the GPS problem I mentioned earlier?
[Captivate Android Development] rob989_69:
I've tested voice, it seems fine so far. There is a lag coming from lock. Honestly, regardless of what quadrant may say the phone felt faster running the euro rom/captivate kernal than it does stock with this fix.

I do appreciate the effort of all the hard work everyone has put into this.
[Captivate Android Development] _Opiate_:
Hopefully that mic bug can be ironed out.
[Captivate Android Development] systoxity:
wow, great holdover till froyo. hope that lag and phone problem can be fixed. thanks every one :)
[Captivate Android Development] ranova:
hmm, tested GPS again on the way home, no dice.

So with horrible voice\mic, no gps lock, slow wake up, and no performance boost seen, I think I will switch back to stock kernel for now and do the NAND trick. high scores in synthetic tests like quadrant dont beat precedence over real world usability.

I'll keep a look out for further updates, thank you NukaCola for all the hard work - I hope my donation helps further in your beer fund :)
[Captivate Android Development] _Opiate_:
You should really give the ext3 partition kernel a try. I've been running it for the last 12 hours with the super Mario live wallpaper and the phone hasnet even stumbled once. Of course the mic problem is still there (hopefully will be resovled soon) and I haven't tried GPS so I couldn't tell you about that.
[Captivate Android Development] ranova:
well I never had any lagginess due to live wallpapers like the mario one. Calling and GPS are big factors for me :/
[Captivate Android Development] _Opiate_:
Lol yeah I hear you....fortunately I have two other android phones I can use while I'm testing my Captivate.
[Captivate Android Development] shep211:
Can anyone post a link to the NAND trick please?
[Captivate Android Development] ranova:
http://xdaforums.com/showthread.php?t=737829

I only do specific apps (google apps, launchers, etc), since my whole data dir is over 200mb.
[Captivate Android Development] _Opiate_:
I sure wish there was an app that would tell you your data directory size so you could check it on the fly instead of needing adb.

IM sure there's a way to use a terminal emulator to check but still.
[Captivate Android Development] _Opiate_:
Looks like im going back to the good old NAND lag fix for now...hope a new kernel comes about soon.
[Captivate Android Development] kennethpenn:
Same. Still thanks to NukaCola for the work put in!
[Captivate Android Development] _Opiate_:
+1 Thank you NukaCola for all the work ur doing for us. Im looking forward to the release of an updated kernel.
[Captivate Android Development] larry996:
applied the updated kernel posted here for ext3, and now when I make calls the other person says my voice sounds garbled. Switched back, restored phone and applied the NAND fix, runs just as well.
[Captivate Android Development] Unhelpful:
trying other filesystems

I've built a new kernel that uses the deadline I/O scheduler by default, as well as supporting xfs, jfs2, ext3, and ext4, and tries to mount both internal and external flash partitions using what should be good mount options for each of those types. I suspect that both bad Quadrant scores and obvious lag with "fixed" devices relate to slow database operations, as this is the longest-running individual test and apps that use databases heavily also seem to be slower. I'll post results when I've had the chance to try the different filesystems.

The kernel is here if anybody wants to try it, but please bear in mind I have not tested all of these filesystems, and you should use at your own risk, have backups ready, etc. ;)

EDIT: It looks like more was wrong with my initial test than just an unsupported option for ext4. I'll update the kernel when I have one that can at least mount ext3/4 correctly. The mount syntax used in init.rc is a bit odd, and I tried running busybox to mount, but that clearly doesn't work as expected. can whatever interprets init.rc be asked to run a shell script? It would be nice if, for example, it could source a user script that gave device, mountpoint, and options, or could use use the busybox mount applet, among other things.
[Captivate Android Development] NukaCola:
We thought we were all setup, but not so much ;)

Seems we ran into two issues, A) voice quality (outgoing) got really bad. and B) we now experience a 3 second or so lag when coming back from sleep. The lag is not percent if the phone is plugged into power.

Did you have any of these issues on the i9k?

What toolchain do you use, can you link to it please?

Any other tricks that we need to know to solve these issues?

I was thinking about trying xfs, its been my fs of choice for a long time ;) However it does even more mucking about on the block device than ext3/4 (hey with a fsck that only does `exit 1` you have to do a lot of internal consistency checking).

Unless jfs2 has changed a lot over the last several years, it is very slow.

Does your kernel have the 'sleep lag'? Do you have the voice quality issues?

I'm not going to be able to work on this much today, but I'm sure we'll find solutions to these issues before too long. I hope.
[Captivate Android Development] _Opiate_:
Ill give that new kernel a go soon. So what he is sayin is that kernel will mount either an ext3 or ext4 partition?
[Captivate Android Development] NukaCola:
You can only use binaries that reside in the initramfs, remember no block devices etc. are mounted yet.

And yes, the stock mount binary is crazy and doesn't even behave as documented. go figure.
[Captivate Android Development] Unhelpful:
Yes, it also appears to silently discard mount options it doesn't understand, like most of the interesting ones for ext4. I had thought, however, that since /system is mounted before /data in init.rc, using /system/xbin/busybox should work.

If the problem has to do with aggressive sleeping of the external SD, and its wakeup time, tweaking FS options probably won't help anyway. The tricky part here will be formatting and copying over the internal /data, since we can't just pop the card out and do that on a PC.

I've seen several mentions of a userinit.sh, but can find no documentation about it. Is this supported by the stock init, and if so, where is it searched for?

Oh, and sync on sdcard ext4 takes a second or so - even if just synced. Does ext4, as of 2.6.19, still have the issue where fsync == sync? Because that would certainly explain the poor DB performance, sqlite wraps each operation in a transaction if one does not create a transaction explicitly, and each transaction fsyncs the DB file on completion.
[Captivate Android Development] Unhelpful:
lag

I should note that while the kernel I linked above will not successfully mount anything but the internal flash on /data, it seemed to behave as well as stock in that case - the UI could be a bit laggy in general but did not stutter or show excessive delay on wakeup.
[Captivate Android Development] NukaCola:
I just flashed back to bone stock, there is a 2 second lag that also goes away when plugged into power.

I just looked this up this am as well, seems anomalous3 over in the vibrant section came up with a nice hack that replaces the boot animation player with a shell script.

Wait, if sqlite does an fsync() on each transaction then fsync() == sync() should be a speedup, since sync() takes Nsecons (isnt it 3 minutes?) on ext4 while fsync() is immediate.

If the issue is sqlite doing a fsync() constantly i dont know if we'll be able to get around that with the filesystem.

Maybe we need to hack up some benchmarks that can do some writes/reads to our different partitions and filesystems. And throw in some sqlite read/writes in there too.

I have to go to a wedding so I'll be gone all afternoon/night and cant work much more on this until monday or tuestday, so enjoy ;)
[Captivate Android Development] NukaCola:
So perhaps the internal sd is woken up before/faster than the extenal. Seems logical that it would get woken up first.

Does your kernel also have the voice quality issue?
[Captivate Android Development] Unhelpful:
lag

I'll look into that. Having a real shell available when mounting filesystems means that we can also test if a mount succeeded instead of just trying each fstype.

No, I mean that ext3 syncs everything on fsync, or at least it used to. I don't know if this was ever fixed in ext4, or what the state of ext4 was as of 2.6.19, but flushing everything on fsync is not going to help sqlite at all, and is the main problem I thought might be avoided by using xfs or jfs. If fsync can generally be expected to have the same performance as sync, this would explain the very slow DB write testing. As far as fixing this issue, the correct fix is in the application - data is fsynced at transaction close, and an explicit transaction around a large batch of operations will prevent the poor performance of running the statements separately and having each enclosed in an implicit transaction.

It may also be that external goes into a deeper sleep state than internal does. I'll be trying internal ext4 next.
[Captivate Android Development] NukaCola:
Yeah, I think we were/are on the same page on that one, and if the issue is that fsync/sync on ext3/4 is borked xfs should help.

Yeah, I'm really lo oking forward to the results of that test.
[Captivate Android Development] Unhelpful:
It's turning out to be rather a trial. I can't unmount internal-data since external-data mounts over it. Support in clockworkmod for formatting a device with a given filesystem would be a big help here. It looks like I will need one kernel (which does not attempt to mount the internal sd at all) to be able to format and copy data to it, and another to actually use the result of that.

The mount installed in the system doesn't even support the convention used in init.rc... and those "on foo" statements are odd. I suspect more and more that these rc files are run on their own interpreter. Maybe there is a "shell" command I could use to run an actual shell script? This would provide an easy way to hook in a userinit script, and would also allow us to hook a user script for any specific action we choose, by providing a shell script in initrd that performs the default action unless a userscript exists.
[Captivate Android Development] NukaCola:
Here is a kernel that will mount mmcblk1p2 on /data but not mount mmcblk0p2 at all. Its tested (has same issues as the other ones) but it boots and runs fine, if you yank your card with this kernel Im sure something fun will happen.
[Captivate Android Development] Unhelpful:
I've figured out how to run a proper shell script from init.rc. I need to do a test to make sure that it's blocking, because otherwise it's not much use for a mount script, but if scripts can be run from init.rc and init.rc can be blocked until they complete, what I have in mind are three scripts added to the initrd and called at specific places. One would run after /system mounts, mount the external SD, move a script from there to /system/etc if it exists, and then run it. This could be used, for example, to update other hooks even if the device won't boot. Another would mount /data, but would check for a script to do this in /system/etc and run that instead. The third would run a userinit script after everything is mounted. If that works it should be much easier to do things like boot with /data on external SD to reformat the internal SD, and other such messy things like that.

Oh, and ext4 on internal shows obvious stuttering during bootanim, and eventually hangs without ever completing startup. I'm going to work on my hooks first so that I don't have to switch to Windows to reflash a kernel to change the boot process, then I'll see about trying JFS or XFS on internal. It's a real shame there doesn't seem to be a robust flash filesystem for linux that can run on a block device instead of mtd - something designed for cf/sd would almost certainly perform better on them than any of the choices we're trying here.
[Captivate Android Development] _Opiate_:
Good luck. Please keep us updated.
[Captivate Android Development] ranova:
quick note:

Reverting back to stock kernal fixed all of the said problems (bad voice quality, slow wake up time) AND I could also get a lock with GPS outside.

I really think the no GPS lock is also part of the bugs.
[Captivate Android Development] NukaCola:
No, I had great gps running those kernels, your gps issues are standard galaxy issues. The other problems are real however...
[Captivate Android Development] sl8125:
The weirdest thing just happened. I applied the init.sh from vibrant forums. It didnt work on my first couple of trys. Today I tried it again. It worked. But forgot to un do modaco fix. So I removed the fix. Then data and voice was gone. How ever before I removed the fix, I was running the init.sh fix for the day. Quad bench was around 1500 and this thing was fast. This was the fast est my phone was ever. I like too see if this fix can run on the captivate. Ext 4 quad was fast. Besides the side effects, running programs were not that fast. Just thought I report my experience. I really like to see if you guys can work this.

Real world speed was good.
[Captivate Android Development] rob989_69:
Dumb question, but what are the steps to flash back to the stock kernal? Do I load it as a CSC or PDA?
[Captivate Android Development] ranova:
CSC, same as the hacked kernels
[Captivate Android Development] autoxer:
Actually, I could only get Odin to work right flashing the stock one back as PDA, even though the hacked ones worked fine as CSC. Either way, it seems to go to the right place, and my phone works fine.

So, basically, YMMV.

I've had a busy weekend with other stuff, but I'm going to see if I can't dig into the kernel source tonight and maybe help get this fix running bug-free. Major thanks to NukaCola for getting it this far so quickly--performance is great, and unlike some guys, I definitely see real-world benefits, not just Quadrant scores.

Loading the "manage apps" and filtering for "all" in the settings is especially quick; loading the pop-up screens for widgets, etc is also very quick, and apps populate in the folder much faster. Not to mention the phone is completely usable about 10 sec after a fresh boot, versus 1-2 min without the fix.

In other words, I think this is worth some time. Hopefully Mimocan will work his magic so my amateur attempts won't be needed, though.
[Captivate Android Development] rob989_69:
Thanks, I went ahead and flashed as PDA and it worked fine. So apparently both work??

Anyway, just wanted to note a few things regarding this kernal that I noticed, I did in fact have the voice issue everyone else is seeing, wifi didn't work at all. Wouldn't connect to any networks. I saw NO real world speed, the euro rom was way faster with the exception of quadrant scores.

Hopefully you guys can get this up and running. Many thanks to everyone that has put time into this. Wish I knew even a fraction of what you guys are doing but Android is totally new and Linux is french to me...
[Captivate Android Development] CaptainTaco:
I'm going to quote... me... on a different thread, because I think it pertains to this as well. I don't understand how the concept mentioned in the original post would help speed what-so-ever, other than tricking a benchmark into giving higher scores... For a more detailed explanation / inquiry, see my original text below.

EDIT:

However, I should mention that you would theoretically potentially see real world gain if you are able to fit all of the data requiring write access into RAM without reaching it's limits... If this was the case I suppose you could see improved performance in that RAM is much quicker any other memory in the phone... Right up until your application needed to read from /data/data... then you are reading off the SDcard and NOT RAM... in other words, all your speed... gone... again, why the benchmark is fooled, it likely reads the data still cached in RAM, not ever needing to touch the painfully slow SDcard. In other words, this won't happen in the real world... in the real world you won't be reading from RAM, just your SDcard.
[Captivate Android Development] rob989_69:
That makes sense. I've said a few times, the Euro rom was much faster, real world, than this fix. I thought maybe it was due to the bugs but maybe not??
[Captivate Android Development] ranova:
yep, I stated this before earlier. Compared with the NAND hack, using EXT4/3 for the /data did not show any real world speed improvements for me, and just huge benchmark numbers. I believe the fastest you can get your phone currently is i9000 JM2 fw + Samset + NAND speed hack, but you are limited to 130 mb of NAND
[Captivate Android Development] rob989_69:
I agree, at least regarding the Euro rom. It's smokin. The 130mb limitation is not a big deal for me. I'm really looking forward to some 2.2 roms to start hitting soon.
[Captivate Android Development] AJerman:
I respect all of your opinions, but 100% without any doubt in the entire world, my phone runs MUCH faster with this mod. It's not opinion, it's not benchmark, I can see that the difference is absolutely there. One time when I booted off the stock kernel without an SD card and had to wait for it to load data off the stock partition, I realized (again) how incredibly long it took the phone to become usable on a stock setup. It becomes usable MUCH faster with this mod.

So think what you will, and as long as you're happy with your setup now, fine, but I KNOW it's not a false benchmark only. And I use boot up as my example because that removes any chance that anything was cached in the RAM from previous use. Everything else is much snappier too.
[Captivate Android Development] ranova:
can you test the following apps:

1) Facebook - how long does it take to refresh the news feed and how long does it take for profile pictures to show up as your scroll down

2) Twitter - how long does it take to refresh tweets

3) Dolphin hd browser - can you consistently scroll through a large page (engadget.com) with the volume buttons without any lag. Can you also open and close tabs without lag?

4) Touchdown Exchange for 2.x - how long does it take to open up an email, goto your calendar, etc.

In all cases, it should be instant. After using Ext4, it all took 3-7 seconds for each (longer for facebook profile picture scrolling), which was no different than stock. Once I reapplied the stock kernel, and reapplied the NAND trick, everything was 1000% faster (except quadrant, got around 900 in that vs 1798 with ext4)

Which method are you using (ext3 or 4), what type of microSD card do you have? (size, class, and manufacturer). I've tried only ext4 with a 8gb class 4 Kingston microSD and got 1798 in quadrant.
[Captivate Android Development] NukaCola:
I agree with AJerman completely. As for your app tests:

Facebook - I dont use it

Twitter - Dont use it

DolphinHD - runs screamingly fast, no stutter. Ever.

Touchdown - dont use it

Anyway, it seems that this mod may not do much for database read/writes and if you are used to mods that address that problem and you use apps that are heavy db accessers.. then yeah I guess your real life usage pattern may not be helped much. But just starting, running and switching apps is snappier with this fs mod.
[Captivate Android Development] _Opiate_:
I had pretty good luck with the ext4-3 setup as well and as soon as that aweful mic issue is fixed ill be all over it again.
[Nexus One Q&A, Help & Troubleshooting] bootoo:
Greeting all,

First of, I would like to thanks all of you for the amount of info I have found in this forum.

This is trully amazing and, so far, allowed me to sucessfully:

- Unlock my phone

- Root my phone

- Install a custom recovery image

I know that I am creating a new post on a very known and discussed subject BUT after 2 days of google seach nothing I have tried has permitted me to sucessfuly delete this £$%^&*() of script.

As you all know, it needs to be deleted to launch the custome recovery image (at the moment, I am stucked with the exclamation mark with the little Droid when I try).

IMPORTANT: I currently run the Froyo android 2.2 official ROM.

To delete this scipt, I have tried 2 approaches:

- Console mode from windows using ADB

- directly form the phone using a File explorer

#1: From the console:

As mentionned in many previous posts, I have tried the following commands once connected to the nexus

adb shell

su

mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system

I beleive this command is either incorrect OR no longer working with Froyo 2.2 as I get the following message which looks fishy (I am not a Linux specialist...):

Usage: mount [-r] [-w] [-o options] [-t type] device directory

When I try to delete the scripe with the commande below, I am kindly informed that it failed as it is still a read only file system

rm /system/etc/install-recovery.sh

#2: From the phone

I read that SUFBS, a very nice file explorer was available on the market allowing to mount both system AND data in RW would allow me to do it.

I have had several try at it enabling RW at different moment (System then etc then directly when I am in the folder and see the script I want to delete) and whatever I do, each time I select the command delete, it looks like it works (little pacman eating) but the script from the dark side is sill there like nothing happened...

As I am close to give it the microwave treatment to see if it works better ;-) I thought I give it a try on the forum to see if any Android/Linux god would spend 5 minutes to explain to me what I am doing wrong...

Thanks a lot in advance!

BooToo
[Nexus One Q&A, Help & Troubleshooting] fubaya:
Try this:

mount -o rw,remount /system

I can't guarantee that works with Froyo but it's all I've ever used and I don't remember it giving me any problem when I used Froyo.
[Nexus One Q&A, Help & Troubleshooting] ilostchild:
Umm I think it should be mount -o remount,rw then type the rest

You can also try this mount -o remount,rw /dev/block/mtdblock3 /system
[Nexus One Q&A, Help & Troubleshooting] fubaya:
adb is supposed to have it's own remount command for doing this, but I've only used adb once when I rooted so I'm no help there.

Other than that, try doing: ls -l /system/xbin/mount to see if mount is a link to busybox. If it is, the last part of the output will look like this: /system/xbin/mount -> busybox

If it is, type busybox | head -n1 to see what version of busybox you have.

Heh, I never realized I had those backwards compared to how people usually do it, but the order doesn't actually matter. It's not necessary to specify the device as the remount option doesn't change the mount point or device.

# mount | grep system

/dev/block/mtdblock3 on /system type yaffs2 (ro,relatime)

# mount -o rw,remount /system

# mount | grep system

/dev/block/mtdblock3 on /system type yaffs2 (rw,relatime)
[Nexus One Q&A, Help & Troubleshooting] bootoo:
Well...

I am an ass...

I did not have enabled the "USB debugging" on the phone...

Problem soved with the exact command lines I put at the beginning...