I think you right, I have the same impression.

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.

@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?

The brainstorm has been upgraded to "Under consideration". Can a moderator change the forum thread title to reflect this?

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.

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

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.

On a side note. Comment on the bootchart... that's so painfully slow.

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)

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".

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.