If that's the ONLY reason, IMHO this option was wrongly ruled out.

For all purposes, the rootfs (not the original, but the original + overlay combination) is perfectly writable. Only for a phisical reflash some steps would be needed to do it correctly, but again, in the current configuration a phisical reflash would also leave /opt somewhat out of synch.

In fact, a process to prepare for a reflash / resynch can be made before the update using the mini_fo approach. I had to do it many times with OpenWRT and never had a problem.

I have read about a watchdog proccess that detects delays in writing during boot and hangs, which could be of some concern, but that also seems to have been solved by Egoshin.

I would leave things at they currently are on nokia side, making now a change is nonsense and would lead to some troubles, but I think the mini_fo modification is perfectly compatible and would add the advantages of:

1- Avoid hang on boot.I have read in some older posts that completely filling rootfs prevents the system from booting. I hope that there's already a workaround for this in PR1.2 or some other third party util (bootmenu?). The workaround would be simple anyways (a 10MB file that gets removed on boot and reacreated after suceess), but I am not sure if my current configuration is protected against that and even after the effort being done in optifiying some apps may fail and cause some havoc.

Ie: Fring for N900 creates a HUGE log on /. I only used it a couple of times for testing and the other day I say a 25MB log file in /, which I have already symlinked to another place as a workaround.


Nokia-N900-51-1:/# ls -al /fring.log
lrwxrwxrwx 1 root root 14 Aug 2 03:29 /fring.log -> /max/fring.log
Nokia-N900-51-1:/# ls -al /max/fring.log
-rw-r--r-- 1 root root 22531688 Jul 14 15:40 /max/fring.log
Nokia-N900-51-1:/#


Luckily, being a log file, its real occupation in ubifs is much less or otherwise it would have nearly filled it.

Also, I have many binaries and libraries directly moved from easydebian chroot to main os which are not EXPECTED to need to write anything to / but one never can be SURE. (Yeah, It may be wrong to do that, but for me it gets the job done and no problems YET).

2- For developing, it is the SIMPLEST way to have different customizations on boot and making sure you have a perfectly fresh system is just a matter of mounting an empty overlay on top of original rootfs.

In my tests, I have confirmed that using a loop interface even with an image file stored in /home/user/MyDocs adds almost NO noticeable overhead. So I don't expect mini_fo do it either. Also I have seen no noticeable differences between ext3 and FAT fs. The bottleneck is always emmc speed... unless you start playing with a truecrypt image file (10 times slower in writing, 2 or 3 in reading) which rules it out for anything except selective storage.

Well, if there are no other reasons against this method, I think it is time for testing... I see unionfs kernel module is included with titan kernel, but I don't find mini_fo... is there a package somewhere for the missing modules?

I would appreciate any other suggestion or something I should take into account before trying.

Thanks!

In the meantime I am trying to decide which would be the best fs for the overlay.

Jffs2 seems a good choice in this case, and it also seems to offer some control for compression settings (perhaps no compression is best as N900 doesn't have much space limitations, unless it noticeable reduces write times) and also for setting when garbage collection may be done. I like that it allows for atomic operations and that it is flash friendly.

Garbage collection might be posponed until on charger AND idle, providing the overlay is adequately oversized.

Have anyone done any benchmarks of jffs2 or any other flash friendly fs in N900?

My only intention is to have an overlay for /, with no changes to the rest of the system. The idea is just to have an oversized rootfs just in case **** happens, and also for having multiple overlays for different purposes. All the rest (/opt etc) being unchanged.

For /opt lack of space I am just using a combination of additional loop mounted images and symlinking which works ok for me... I don't see any issue there.

appnss, I wonder if your ideas are worth chatting with the MeeGo team, e.g. stskeeps or similar mentioned at http://wiki.meego.com/ARM/N900

You can only use jjfs2 over the mtd layer, and note that UBI is "kinda" its direct successor.

@pelago

Probably the only idea that is worth trying is the mini_fo overlay. Which I would have already tried if I had found mini_fo.ko for titan's kernel.

I am downloading the SDK and will try to make a compatible module... Should be easy, but it's been a very long time since last time I had to recompile a kernel myself. I hope not to break anything :P

@javispedro

Then I guess ext3 would be the most reasonable choice, at least for now.

An update about the mini_fo solution I proposed:

After enabling native compilation I discovered that mini_fo isn't updated anymore. The only update/patches available are those from the OpenWRT project which hevily relies on it.

mini_fo as it was doesn't compile against kernel 2.6.28 so the only way (that I know of) would be to backport mini_fo from OpenWRT and I haven't had the time to do so.

Anyways, I cracked my lcd screen in the meantime I had time to think about it. Now I think the better approach is to just leave maemo as it is, perhaps increasing the size of /opt partition or adding additional image files to increase it and move/symlink stuff over there.

And have another chroot'ed environment, a maemo one (in contrast to easydebian, etc), in which to have a second system, including a native compiler with which to compile every needed programs without having to care about optifiying. It works perfectly and the underlying original maemo keeps unharmed.

For me, it's the way to go, and it covers any need I can think of.