yes back in the early days, in pc's you could get even better performance with compressing because HD's where really slow compared to the processor.

But with the way flash works.. i dont know if this is really a gain..

For example reading 1KB will result in a read of 1 Page (mostly 4KB)

and writing is especially with not so performing i/o controllers is done in Blocks and those are X number of pages of total sometimes 512KB at total.

So to write a 1KB block 512KB needs to be read in. 1KB updated in that block and then 512KB written again.

But this all depends on what kind of flash controller is in the N900...
But i cant believe that with flash we really gain much in read speed and write speed is really a bit slower..

Note that we have done some benchmarks on the real filesystem performance
for different media and filesystem http://talk.maemo.org/showpost.php?p...2&postcount=76
The NAND results are the best case scenario, as only a highly compressable stream is written.
Real life scenarios may be much worse and are on my todo list.

You can also find my ideas for a "full optification" solution on
http://wiki.maemo.org/User:Tanner#full_optification

Like I said, this isn't a workable solution. Then each reflash would require overwriting user data.

Not. An. Option.

Please pleas lern about the FHS before posting such things.

/opt is there for things that AREN'T packaged by the distribution. And the format is generally:
/opt/$VENDOR and then whatever layout under that.

Here's the relevant link to FHS:
http://www.pathname.com/fhs/pub/fhs-...FTWAREPACKAGES

Some alternate path like /usr/local would probably be a better idea in this case. Or even using unionfs-fuse on top of /usr infact that would be nice. Be always able to just unmount all the modifications.

There is one an effective way to solve this problem. It can be not easy -

put all root (besides boot) into 32GB flash and use fast 256MB space as a cache for disk blocks. Initially it would take some additional time and battery to replicate blocks into new 256MB cache but later it would give a fast access to frequently used data with virtually unlimited space.

It is possible just to extend kernel cache interface to include 256MB into it. But to get the result permanent via next reboot it may requires some additional development in FS.

no, /opt is for add-on software. Everything not shipped by Nokia (i.e. software from extras or Ovi) could be considered as add-on packages. Packages can be installed under /opt/<PACKAGE> and symlinked to /opt/bin or /opt/maemo/bin.
/usr/local is reversed for local installations, i.e. self compiled programs.

No desktop GNU/Linux distro follows the FHS to the letter.

(oh, and btw: yet another /opt thread > ).

I am sorry GeneralAntilles, I seem to have missed your earlier reply to this. From your latest response:

From this, I take it that there are two basic problems:

1) The device needs to be capable of getting to a guaranteed stable functioning state from a reflash
2) The reflash should not delete the user's data in the eMMC

At least those two seem like the reasonable requirements.

Well, that obviously means that the most straight-forward method; just installing root in eMMC directly, will not work. However, this is a brainstorming forum, and finding solutions when the most naive approach fails is the whole point of brainstorming. Let's not get disheartened quite yet!

I think that most agree that optification is not good as a long term solution. As such, we really do need to tackle the issue as soon as we can! Until we have it fixed, we will continue to see newbies getting into trouble such as this (the guy ended up re-flashing his device). I would like to argue that a solution will have to be very convoluted before it is worse than optification, so we do have quite a bit of leeway for ideas.

I've been experimenting with aufs, unionfs and mini_fo for a while to mount ext3 partition on top of internal memory. All of them have problems.
One common problem was that both of the file system partitions needed to be writable. It is because of the complex algorithm when renaming non empty folder from read only file system (aufs page has a good explanation on that). For example application managed did not work because of this problem. So mini_fo did not work at all.
Aufs is most flexible in configuration. But for some reason with it phone stopped playing video. And the battery did not last long with it (~6-8 hours). And I could not get the file system to umount during shutdown so I had a lot of lost data and sometimes after shutdown phone was unusable.
Unionfs was more stable. I did not have the problems aufs had. But it was impossible to set priorities on where to write new files if there are two writable file systems. Everything was written in root file system as it already contained folders where the files were written. Unionfs has awful documentation. It was not easy to find that it was the default behavior for new files. And I could not find how to change that. So very quickly I ended up with 0 bytes left in root file system.

Right now I moved everything to the card and change the root file system to the card during boot. But I had to enable R&D mode and disable watchdog for it to work. While I was experimenting watchdog was only casing trouble. Right now I am searching for a way to remove it from the system.
With disabled watchdog system boots fine from card and everything works fast. When I moved only /usr to the card without disabling watchdog the system was slow and unusable. And it was impossible to move the whole root to the card with it enabled.
I can upload my modified firmware if someone wants to test it. It will write root file system image to the internal mmc card at the first boot and after that it will be booting from the card.

@titan: I was just going to suggest that you add your ideas as a solution, but noticed that you have already done so. Thanks, we need to examine some solutions!

I would also like to concur with javispedro: There are many other discussions about /opt and the FHS around the 'net. Lets keep this discussion to the problem of finding a more robust way of using our two flash drives in the N900, rather than discus how standards should be adhered to or interpreted.