maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Brainstorm (https://talk.maemo.org/forumdisplay.php?f=47)
-   -   [Under consideration] Remove 256MB limitation of the rootfs partition in the N900 (https://talk.maemo.org/showthread.php?t=43833)

egoshin 2010-02-10 02:48

Re: [Waiting] Remove 256MB limitation of the rootfs partition in the N900
 
Quote:

Originally Posted by shadowjk (Post 518701)
The mmc type chips are designed for single-tasking camera/media use, they hide the flash/nand behind a dumb controller which is fully optimized to be cheap and simple for large file use. It doesn't really handle the random updates of 4k blocks here and there very well.. Its native block size is something like 256k, so a random 4k write gets translated into a 256k read-modify-write cycle.

I think you right, I have the same impression.

Quote:

A factor of 10 difference! nilfs2 is by accident and its nature faster on flash.
nilfs2 may have a problem then device can be almost full. Garbage collection would be not simple for battery powered device. It should be delayed until N900 is on charger.

stefanmohl 2010-02-10 03:12

Re: [Waiting] Remove 256MB limitation of the rootfs partition in the N900
 
@sr: I did see your previous post regarding aufs and unionfs. Great work in coming up with those results, even if the results themselves were kind of depressing! One thing I was wondering about though: If I got what you were doing right, you were using a ram disk backed by a flash drive; essentially your ram-disk was a write-through cache backed by the flash.

For the root partition problem, the situation is slightly different - both backing and front store are persistent. In this case, the fast flash stores the clean Nokia distro and the big flash stores all user additions. The big flash is superimposed over the fast flash so that reads see the big flash first, and writes only hit the big flash. This is more of a read-through rather than write-through scenario, if you get what I mean. I also assume that writes to files that already exist in the fast flash (i.e. modifications) go directly to the fast flash, rather than stick in the big flash like normal writes.

Do you think unionfs is so hopeless that there is no point in trying, or do you think you could have a look at how unionfs works in those conditions? Your basic idea is so pure and elegant that I really hope there is a way of saving it!

Does anyone here know anyone working on unionfs? Are there any Nokians here? Could Nokia consider putting in some work on unionfs?

stefanmohl 2010-02-10 04:36

Re: [Waiting] Remove 256MB limitation of the rootfs partition in the N900
 
The brainstorm has been upgraded to "Under consideration". Can a moderator change the forum thread title to reflect this?

ruskie 2010-02-10 06:24

Re: [Waiting] Remove 256MB limitation of the rootfs partition in the N900
 
Well I use unionfs-fuse myself for some alternate use and thus far was rather happy. I am considering using it on the N900 as well.

Of course something like nilfs2 would be nice on the flash as well but I think a more recent kernel would be a good idea first.

titan 2010-02-10 07:50

Re: [Waiting] Remove 256MB limitation of the rootfs partition in the N900
 
regarding performance: on a HDD nilfs2 performance was not so great
http://www.phoronix.com/scan.php?pag...s_nilfs2&num=1

My benchmarks http://talk.maemo.org/showthread.php...332#post504332
showed that real fs performance on NAND is not that much better than eMMC:
in the best case (compressed zero data) seq. write was 8 vs. 24 MB/s, seq read
19 vs. 30MB/s but with much higher CPU load for UBIFS.
I expect the differences to become much smaller with typical data.

If eMMC is not much slower, the firmware could copy the whole rootfs to a partition on eMMC at the first boot and from then on forget about NAND and boot from eMMC.
We need some benchmarks for booting from eMMC vs. NAND. Perhaps some of the differences are caused by the watchdog?

@slaapliedje: most boot stuff is in /usr and not in /bin or /sbin
see https://arch.nord.thebc.ch/wiki/inde...sing_Bootchart

ruskie 2010-02-10 08:10

Re: [Waiting] Remove 256MB limitation of the rootfs partition in the N900
 
Quote:

Originally Posted by titan (Post 518928)
@slaapliedje: most boot stuff is in /usr and not in /bin or /sbin
see https://arch.nord.thebc.ch/wiki/inde...sing_Bootchart

Yeah sadly. It doesn't follow any of the normal desktop Linux policies in that regard. I wonder if this can actually be fixed by nokie with an update sometime. It would certainly improve the ability to hack it around without breaking it(had it happen a few times).

Anything that is needed to boot the system to a point of mounting /usr should be directly in / not in /usr.

Maybe have a USR_OK event in upstart that would tell the rest of the scripts that USR is ok. It could be a dummy as a start but could be replaced by one that would mount it.

ruskie 2010-02-10 08:18

Re: [Waiting] Remove 256MB limitation of the rootfs partition in the N900
 
On a side note. Comment on the bootchart... that's so painfully slow.

titan 2010-02-10 08:38

Re: [Waiting] Remove 256MB limitation of the rootfs partition in the N900
 
for those of you who want to play with unionfs: I have uploaded a new kernel to extras-devel non-free
package "kernel-flasher-maemo" (see http://talk.maemo.org/showthread.php?t=43420)

javispedro 2010-02-10 11:48

Re: [Waiting] Remove 256MB limitation of the rootfs partition in the N900
 
Quote:

Originally Posted by titan (Post 518928)
regarding performance: on a HDD nilfs2 performance was not so great

Now consider that a whole lot of that eMMC throughput will be consumed by swapping in/out and you see why some people report that it is "insanely slow".

javispedro 2010-02-10 12:12

Re: [Under consideration] Remove 256MB limitation of the rootfs partition in the N900
 
Also, please consider recent improvements in the optification "art". Since it's already creating the symlink forest at package postinst configure time, patching dpkg to "autooptify" packages at runtime doesn't sound that far fetched.

IMHO, it's not an awful solution.


All times are GMT. The time now is 08:34.

vBulletin® Version 3.8.8