Share this post

Link to post

Share on other sites

First, a hearty thank you to those who have posted so much valuable information, notably Paul, who posted the original lag fix. His is the one that worked for me, and it was fairly easy really. Eventually.

I am a n00b indeed, having never before dealt with anything remotely Linux. I was so excited to get my first Android phone, the Vibrant, this after having been a staunch BlackBerry user for the past few years. I started reading forums...started seeing things like the GPS problem, the lag problem. AH HA! So I WASN'T imagining these things...

I just had to has root. I'd been hearing about it for so long! It was easy, easier than in days gone by I learned. A .zip file on the SD card then reboot...sheesh. I suppose I'll never know what it was like in the olden days. Piece of cake. I continued to read the forums before really doing much of anything else. One thing I picked up on early...get ROM Manager and do backups. So glad I did...

I've learned the hard way through the years with Windows...backups are good. Very good. Only the most reckless do not have them. Once I got ROM Manager I did a backup...after that, I told myself, I'd continue to try different things. This proved to be wise.

The first time I tried the lag fix...after reading literally hundreds of forum posts, I began to develop a rudimentary understanding of what was going on. Now, making ext3 partitions and such...too much for this feeble mind. But the rest, all about the memory, the essence of the original fix...these things were more clear. I decided to give it a try after reading a bit on ADB etc. However, knowing my proclivity to botch things, I made another backup first, this after having used Root Explorer to get rid of a few useless-to-me programs (read a lot of posts about that too).

Now, being nearsighted and having a high-resolution computer screen isn't always good. Those few-in-number commands to fix the lag...yeah, you guessed it. I blew it the first time I tried it. Gad, it was ugly after rebooting. The horror of seeing error message upon error message! But wait...I made a backup prior. What, I had a choice at this point? Reboot to menu...nandroid...ah, I see it...that's what I want. Oh look! There's the backup I made but moments ago...okay, pick the right one...

Glorious! The restore worked! Like nothing ever happened. Amazing. Okay...back to ADB to punch in the commands, ever so slowly. Hey, no error messages this time, this with übercareful typing. Reboot...no error messages...sweet screaming bovines! It worked. My Vibrant is stupid fast now! Wouldn't have thought it possible. I can live with this until the Froyo ROM's start popping up.

The moral of my tome...these "hacks," if you will, can work magic. To you n00bs like me, it WILL work. Be careful and deliberate in what you do. Read many forum posts first. And above all, if you has to has the root, BACKUP. Pay the $4 for something like ROM Manager and Charlie Yankee Alpha.

My Vibrant is screaming fast, /dbdata is only half full and I've installed a whole stinkload of apps to play with. Thanks for the learning folks; I appreciate it. I'll never be a chef or a guru, but with some help I can get by and have a heckuvalotta fun.

Share this post

Link to post

Share on other sites

It's late and I haven't gotten to the part where someone explains why we would want to revert to the old data.bak?

why not rm /data/data and then copy /dbdata/data to /data/data and have everything current.

then once this is in place, remove /dbdata/data and /data/data.bak and be happy?

Oh btw, meant to mention, devices with slow IO will suffer stalls quicker than our desktops, but even they feel it.

There are a couple of people working on this, might make it into 2.6.36

Until then, there is BFS, which works fine on desktops and on smaller devices, it would help with stalls. I am sure a kernel for vibrant would make people majorly happy. (Yes, there was a bad version that once made it into a CM4 kernel, and everyone screamed, been a while since, and it's rock solid on the desktop, just a thought.

Moving to /dbdata is like putting a band aid on after you cut off your finger. (It's not a fix, even if it stops bleeding)

Share this post

Link to post

Share on other sites

It's late and I haven't gotten to the part where someone explains why we would want to revert to the old data.bak?

why not rm /data/data and then copy /dbdata/data to /data/data and have everything current.

then once this is in place, remove /dbdata/data and /data/data.bak and be happy?

That's actually the recommendation I've made over in the "real lag fix" thread when using that method. Once you've started installing apps that .bak folder no longer is a backup. Also, it just sits there eating up internal storage space for no reason.

Share this post

Link to post

Share on other sites

I need to get me a boot.img with an init.rc that mounts my /dev/block/mmcblk1p2 (ext3 on sd card)

Mounted it manually over /data/data it's zippy, doesn't waste /dbdata , but without a proper boot.img it's no use, manually mounting is no option each time.

Normal recovery not wiping /dbdata sends you into FC hell if something happens to /data/data :)

wiping out of privacy does wipe it and all is well

Clockwork should add that too.

Isn't that what mimocan's "real fix" does...? He's got a custom kernel for both ext 3 or ext 4, and the ext is mounted as /disk and then you move the /data/data to /disk/data. Works like a charm for me.

Share this post

Link to post

Share on other sites

I have a possibly newbish question here. I saw benchmarks for the filesystem earlier in the thread:

Total file system score 29.770191

Creating 1000 empty files 42.955 sec

Deleting 1000 empty files 24.973 sec

Write 1M into file 3.0750308 M/sec

Read 1M from file 56.81818 sM/sec

Remounting with noatime

Total file system score 70.81754

Creating 1000 empty files 41.438 sec

Deleting 1000 empty files 29.886 sec

Write 1M into file 3.5855145 M/sec

Read 1M from file 138.88889 sM/sec

Why would it take 42~ seconds to create 1000 empty files when it has a 1M write speed of 3.5~/M/sec. Is this filesystem related? The N1 has a slightly slower write speed but is able to create files much faster.

Edited August 12, 2010 by andars05

Share this post

Link to post

Share on other sites

Why would it take 42~ seconds to create 1000 empty files when it has a 1M write speed of 3.5~/M/sec. Is this filesystem related? The N1 has a slightly slower write speed but is able to create files much faster.

Probably. The N1 uses YAFFS2, a file system specifically designed for nand flash memory. The SGS uses RFS, a Samsung proprietary file system that is based on FAT32 (ugh).

The two most popular lag-fix/phone-speed-up fixes rely on putting your data into a file container that's running an ext file system, which drastically speeds up the phone.

My own testing of reading files off the internal nand areas showed that the internal nand is capable of at least class 6 read speeds and not much slower than my class 6 external card on 100mb files, so the original theory floating around that the internal memory was cheap and slow stuff doesn't seem to hold water in my opinion.

The long term fix for this that doesn't require hacks, symlinks, loop mounts, whatever is probably just getting Samsung to switch to YAFFS2, or getting someone like cyanogen or Paul to include formatting to YAFFS2 as part of their customized ROMs.

It's coming up on time to recommend new phones for many iPhone owning friends of mine. I'd love to suggest the i9000/Vibrant/Captivate, but until Samsung fixes this for out of the box non-hacking folks, that's a tough call to make.