3.2 really slow since low disk warning

[Guest boobloo]

I am running 3.2 with all my apps on the SD card etc.

A couple of weeks ago I had a low disk warning so I deleted a load of stuff and free'd up a lot of space, but since then I have found that my Hero is really laggy, it is really noticeable when going into the mail apps & SMS

. Are there any routines I can run in recovery mode to optimize the CD Card again?

I have RA-hero-v1.5.2 installed with a 16Gb Class 6 SD card

Model: SD USD (sd/mmc)

Disk /dev/block/mmcblk0: 16.1GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Number Start End Size Type File system Flags

1 512B 15.4GB 15.4GB primary fat32 lba

2 15.4GB 15.9GB 500MB primary ext2

3 15.9GB 16.1GB 202MB primary linux-swap(v1)

Thanks in advance

[Guest xTc is loVe]

Try to wipe Dalvik Cache! And if this dont Work make a Backup of your settings and wipe data/factory reset ;-) This should work!

[Guest boobloo]

Try to wipe Dalvik Cache! And if this dont Work make a Backup of your settings and wipe data/factory reset ;-) This should work!

what will I lose if I wipe the Dalvik Cache?

[Guest xTc is loVe]

what will I lose if I wipe the Dalvik Cache?

Settings of your Apps. But u can backup the ones u like to hold.

Hope u understand me.

[Guest zorm]

Settings of your Apps. But u can backup the ones u like to hold.

Hope u understand me.

No, wiping the Dalvik cache won't lose anything vital (unlike a factory reset obviously). The Dalvik cache stores optimised versions of the executable .dex file from each app. The only consequence of wiping the cache is that the next time an app is run (or possibly on the next boot - I'm not certain), it will take slightly longer to start up.

Edited April 17, 2010 by zorm

[Guest zorm]

I am running 3.2 with all my apps on the SD card etc.

A couple of weeks ago I had a low disk warning so I deleted a load of stuff and free'd up a lot of space, but since then I have found that my Hero is really laggy, it is really noticeable when going into the mail apps & SMS

Did the warning tell you which device was low on space or have you just assumed it must refer to the sdcard? I doubt I can help, but anyone who can & reads this will probably benefit from knowing how much space you have left on each device. I suggest you post the output from the command df: if you use adb, paste the result of

adb shell df

into your reply.

[Guest boobloo]

Did the warning tell you which device was low on space or have you just assumed it must refer to the sdcard? I doubt I can help, but anyone who can & reads this will probably benefit from knowing how much space you have left on each device. I suggest you post the output from the command df: if you use adb, paste the result of

adb shell df

into your reply.

I'm not sure what it was referring to, but once I deleted the junk off of the SD the message didn't reappear

As requested this this is the output from adb shell df: -

Filesystem 1K-blocks Used Available Use% Mounted on

tmpfs 98064 0 98064 0% /dev

tmpfs 4096 0 4096 0% /sqlite_stmt_journals

/dev/block/mtdblock3 174080 162008 12072 93% /system

/dev/block/mtdblock5 169728 149440 20288 88% /data

/dev/block/mtdblock4 133120 19916 113204 15% /cache

/dev/block/mmcblk0p2 457593 80629 352550 19% /system/sd

/dev/block//vold/179:1

14993144 3385848 11607296 23% /sdcard

[Guest zorm]

/system & /data usage is high but I wouldn't have thought it was cripplingly so. I guess you could make sure if you wanted - uninstall some apps to try to get data down by say 10%. You can always put them back with a nandroid restore.

Hm, I often read that file system fragmentation isn't an issue with linux, but occasionally a vociferous poster claims it can have an impact. If you're desperate you could eliminate that as a possibility too - simply do a nandroid backup & restore (this will work as although the backup is stored as an image of the complete filing system, it isn't created by duplicating the filing system; instead all the files are tar'd then made into a yaffs2 image, thus backup/restore has the effect of copying all the files off, then all back on, which has always been the simplest way to defragment a filing system). I have no idea if this is likely to help, but at the very least it eliminates a couple of possibilities.

Another thing I'd probably try is temporarily doing a clean install of 3.2. If your problems are caused by the current state of your install then you should see this instantly as performance should be restored. If it isn't you can stop tinkering with the filing system & look elsewhere for the cause.

[Guest boobloo]

/system & /data usage is high but I wouldn't have thought it was cripplingly so. I guess you could make sure if you wanted - uninstall some apps to try to get data down by say 10%. You can always put them back with a nandroid restore.

Hm, I often read that file system fragmentation isn't an issue with linux, but occasionally a vociferous poster claims it can have an impact. If you're desperate you could eliminate that as a possibility too - simply do a nandroid backup & restore (this will work as although the backup is stored as an image of the complete filing system, it isn't created by duplicating the filing system; instead all the files are tar'd then made into a yaffs2 image, thus backup/restore has the effect of copying all the files off, then all back on, which has always been the simplest way to defragment a filing system). I have no idea if this is likely to help, but at the very least it eliminates a couple of possibilities.

Another thing I'd probably try is temporarily doing a clean install of 3.2. If your problems are caused by the current state of your install then you should see this instantly as performance should be restored. If it isn't you can stop tinkering with the filing system & look elsewhere for the cause.

Many thanks Zorm

A Nandroid Backup & Restore did the trick

[Guest zorm]

I really didn't expect that to help, just eliminate another possible cause. This is worth bookmarking. A clear case of performance loss due to file system fragmentation. Shame we didn't do some benchmarking to measure performance before & after. Ah well, never mind. Glad you have a solution ;)