DUNIA ANDROID

performed some tests days before and I would like to share the results with all of you. the result was as expected (my expectation)

the test was conducted on /dbdata, using dd to read and write, and with different slice_sync and slice_async values.
According to lwn.net:
- slice_sync: How many msec a sync disk slice lasts
- slice_async: How many msec an async disk slice lasts

in froyo, the default value for slice_sync is 97, and slice_async is 39. while in eclair, they are 100 and 40 respectively.

and, the results were obtained by the average value under different file systems as below:
write: dd if=/dev/zero of=/dbdata/test count=25000 (using default bs=512)
read: dd if=/dbdata/test of=/dev/null

test1: default slice_sync (97), slice_async (39)
ext2 w=0.3563576, r=0.2172932
ext4 w=1.7057048, r=0.1286368
ext2 on ext4 w=0.2786272, r=0.1360666
ext2 on ext4 noatime nodiratime w=0.279215, r=0.124138
ext4 on ext2 w=0.4299866, r=0.1277804

test2: slice_sync (50), slice_async (20)
ext2 w=0.3883144,r=0.2209398
ext4 - omitted
ext2 on ext4 w=0.2743988,r=0.1343098
ext4 on ext2 w=0.4350612,r=0.2513572

test3: slice_sync (500), slice_async (200)
ext2 w=0.4159796, r=0.40419
ext4 - omitted
ext2 on ext4 - omitted
ext4 on ext2 w=0.4252074, r=0.2614818

obviously, the fastest one was ext2 on top of ext4, with only insignificant impact with noatime and nodiratime options (i cant believe it). this combination of file systems performed well as expected since while ext2 do somewhat like "blind read/write", the ext4 will hold the data b4 commit (PLS, pls dont argue ext2 and ext4 with me and that's why i described them very roughly... )


actually this was just for my own leasure but i think it may be useful to u guys as well so i decided to post it here for your ref


more info

after playing with Andriod for a month, I found a way to speed up the Android system by creating loop devices, no data2sd required
no more lags, smooth scrolling/zooming in and out in default browser with a web page contains more than 170 images, much faster cache for browser, market and other apps retrieval and listing

here's how:
- create an empty file with dd (i chose -b 4096 -m 1)
- mount it to loopx and format it with ext2 (busybox)
- create mount points and create links, eg
mount -o rw,noatime,nodiratime /dev/loop0 /dbdata/dbdataimage
then mv files and folders to /dbdata/dbdatimage
so, instead of reading /dbdata/databases/com.1.2.3, it will be linked to /dbdata/dbdataimage/databases/com.1.2.3
- finally write a script to mount them on boot by replacing playlogos1

simply speaking, is to run on an ext2 file block in rfs, and that's all for the trick!!


WARNING:
- i did it for /cache, /dbdata and /data only
- empty files, folders, and sym links will be deleted by the system under /cache
- dont reboot the phone when u've temporarily moved /dbdata/databases to a slow partition like /data


personally, i moved /data/data and /data/dalvik-cache to /dbdata and moved browser and market cache files to /cache

it's not for the benchmark only, instead, it has very good effects on ur phone's io

for the loop device:
busybox mknod /dev/loop0 b 7 0
busybox losetup /dev/loop0 /dbdata/dbdata.img
busybox mkfs.ext2 /dev/loop0
then mount it

and, here's my mount output:

rootfs / rootfs ro 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
/dev/block/stl6 /mnt/.lfs j4fs rw 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
none /dev/cpuctl cgroup rw,cpu 0 0
/dev/block/stl9 /system rfs rw,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/mmcblk0p2 /data rfs rw,nosuid,nodev,noatime,nodiratime,vfat,llw,check= no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl10 /dbdata rfs rw,nosuid,nodev,noatime,nodiratime,vfat,llw,check= no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl11 /cache rfs rw,nosuid,nodev,noatime,nodiratime,vfat,llw,check= no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl3 /efs rfs rw,nosuid,nodev,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/loop0 /dbdata/dbdata1 ext2 rw,noatime,nodiratime,errors=continue 0 0
/dev/loop2 /cache/cache1 ext2 rw,noatime,nodiratime,errors=continue 0 0
/dev/loop2 /cache/market ext2 rw,noatime,nodiratime,errors=continue 0 0
/dev/loop2 /cache/browser ext2 rw,noatime,nodiratime,errors=continue 0 0
/dev/block//vold/179:1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,f mask=0102,dmask=0002,allow_utime=0020,codepage=cp4 37,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block//vold/179:9 /sdcard/sd vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,f mask=0000,dmask=0000,allow_utime=0022,codepage=cp4 37,iocharset=iso8859-
1,shortname=mixed,utf8,errors=remount-ro 0 0


- no need to deal with /data
- the major thing is /dbdata/databases
- it wont have impact when u connect it to ur pc/kies since kies only deal with /sdcard and /sdcard/sd only, which both r out of my concern
- to see the improvement, simply do a dd and u'll see the difference



what suprised me is that, i found in one of the taiwan's forum, ppl called it "Hong Kong's Lag Fix" (香港版卡三爽)

more info (chinese)






more info