Thread: [Under consideration] Remove 256MB limitation of the rootfs partition in the N900
View Single Post
egoshin is offline egoshin
2010-07-08 , 00:45
Posts: 992 | Thanked: 995 times | Joined on Dec 2009 @ California
#93
Originally Posted by shadowjk View Post
What unit is your battery current figure in? How did you measure it?
sleep 15
time dd if=$1 of=/dev=null bs=64k count=3000
time dd if=$1 of=/dev=null bs=64k count=3000
time dd if=$1 of=/dev=null bs=64k count=3000
time dd if=$1 of=/dev=null bs=64k count=3000
time dd if=$1 of=/dev=null bs=64k count=3000
time dd if=$1 of=/dev=null bs=64k count=3000
time dd if=$1 of=/dev=null bs=64k count=3000
time dd if=$1 of=/dev=null bs=64k count=3000
cat /sys/class/power_supply/bq27200-0/current_now

(bq27x00_power.ko module is from Matan's collection)


The big difference for nand vs emmc isn't in sequential read/write.. Whereas the emmc can do something like 4-8Megabyte/s write per second sequentially, the built-in flash translation layer can not at all deal with random write (such as swap, /opt and MyDocs), and the speed for 4K random writes degrades to a few hundred kilobytes.
Swap is not an issue at all - it is read and written in big blocks and it is located NOW in 32GB flash (non NAND!). Also I tested files on /home/user Ext3 - the file read speed is about the same - 19MByte/sec. And reading uncachable /usr/lib/locale/locale-archive from UBIFS gives 18MByte/sec. I don't see a difference besides CPU resource and battery usage.

Short files from /etc and gconfig can land in kernel cache pretty soon. And we may combine file caching in MTD2 for that - it would get the advantage of fast short access if UBIFS implementation works fine for short files.

Besides of that it is possible to use not ext3 but some more flash-friendly FS - LogFS is released in May, for exam.

The OneNand has no FTL, so we can manage it ourselves, and we have a 600MHz cpu and 256 megs of ram, plenty of room to do something intelligent. As a result, the onenand with ubifs is a few magnitudes faster at serving IOs from a multitasking demand-paging operating system.
May be. But I don't see it now - my battery depletes too fast and I know the reason now. Personally, if there is a choice I prefer to have some slow disk access but much less CPU expenses, in my long UNIX experience with old and slow disk equipment it handles file access very well because of kernel buffer cache, especially in multitasking. But I don't think we would have a slow access.

Reads are same magnitude in speed, as long as there are no writes interleaved.
I have a home server which is configured to have root FS read only besides some critical files for X11 which are symlinked to /var and the whole /var is located in Generic Compact Flash. It is done to prevent disk spinning and works very well, at least faster then N900

So, don't worry about writes... well, gconf should be killed or replaced because it writes on any bump. But we can symlink that stuff into OneNAND.