I have updated the brainstorm with the issue GeneralAntilles hinted at, and added a link to the Wiki discussion too.

Please learn what FHS is and how it fits in here. Seriously. Anything that is packaged for a distribution on a regular desktop GNU/Linux system DOES NOT belong in /opt

/opt itself is mostly a historical feature or used by anything that can't/won't be packaged(think proprietary software like DB2, Oracle etc...).

Yes I am well aware of what /opt on maemo does but it doesn't mean I agree with it.

As for /usr/local... yes it's there for things an admin would install... but in this case it could be abused.

Also looking at other systems like BSDs /usr/local is where their packages install by default. Most things out of /usr/local are part of the core system. And this would probably fit maemo more as it would be more true.

Maemo is NOT a regular desktop system, even though I wish it was more similar...
There is no authority which can enforce the FHS. It's just a guideline.
My point is that using /opt is in accordance with many interpretations of the FHS
(maybe not with yours). However, the current hybrid /usr and /opt mix with optifying
larger files is - I believe we all agree here - is a very ugly hack and also not at all FHS
complaint.
I'd be happy with any solution which clearly separates the core system and
the add-on packages, be it /opt or /usr/local.

Hrmmm... I would like to remind everyone, we are looking for a robust way of partitioning our two built-in flash drives and efficiently running Maemo on them.

How /opt should or should not be used according to standards is not the issue for this thread, please take all such discussions in another topic. Please consider any sort of argument regarding interpretations of FHS (how /opt "should" be used) a troll and ignore without response. The Internet is full of debate on that issue; use one of those forums instead.

What about using unionfs and just forget all this /opt ****??? Qwerty12 built modules for diablo's kernel: http://talk.maemo.org/showthread.php?t=19104

No need to optify anything, programs would be automatically installed in a root overlay in the mmc. So good, so nice.

The only thing we should take care is to deactivate it when something should really be installed in the real root partition.

Wouldn't this be a good solution?

I've already replied about unionfs and similar file systems on previous page of this topic and described the problems it has.

Ruskie is correct, with the exception that most Linux distributions put everything that is in the package manager in /usr, whereas if it's not managed by the package manager, it should go into /usr/local.

Titan, while it's technically not a regular desktop system, it basically is a regular Debian based distribution, and putting things in /opt is wrong. While I have seen a lot of distributions deviate from the LSB, almost all of them within the last 10 years have adhered to the FHS. Why? Because the FHS kicks ***, and is USEFUL, and will be useful with my suggestion.

Which is this;

The 256mb should hold / and /sbin, /bin, /root and that is it. That should be ALL that needs to be mounted initially for a Linux machine to boot (I could be missing one, but I'm not sure.)

/usr/bin and /usr/sbin do NOT need to be on the same partition as the one that boots, it can be mounted later. You can even mount it over a network and have all your maemo apps on your server (of course that would be useless when you were out on the road!) /var should be on that separate partition as well.

Most of the space currently that is sucking up the space with the optified packages is more than likely in /var, which is where your apt-get puts files (specifically /var/lib/dpkg/info/. This is where all the deb scripts go after a package is installed). This alone would help a huge amount. The other place that a lot of files go is /usr/share (at least on a normal Linux system). This keeps things clean.

It's one thing to base your distribution off of Debian for apt-get goodness, it's something else to use it and completely ignore the debian packaging guidelines (like Ubuntu Devs tend to do now and again)

It's crazy that they only gave us 256mb for our root file system, Honestly how much more of a cost of production would it have been if they had made that 512mb?

slaapliedje

OK, slaapliedje, you are the first to get a kudos--; as a result of the first half of your posting. I am completely ignoring if what you said there was right or wrong, it doesn't belong in this thread so go put that kind of stuff in another thread (you can make as many as you like, you know).

Enough said about that. Regarding the second half of your posting:

If I understand your approach correctly, you are suggesting we put the bare necessities for booting in the fast flash and everything else in the slow flash. I can see how this would minimize the amount of data in the fast flash, and it would let part of the boot process run from the fast flash (making the boot fast). What strikes me as problematic with this is: Shouldn't we really try to have as much in the fast flash as possible, rather than as little as possible?

Edit:
On further thought, slaapliedje, you are right. We should place only those system files which really need speed in the fast flash. That leaves space for adapting other packages for using the fast flash too, and not only the system (i.e. some sort of speedification, if we assume we install on slow flash by default).

256M was the biggest available in volume at design time..

Anyway, I suspect the difference in performance is mostly because ubifs can manage the nand intelligently. 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. It doesn't take much I/O before the emmc is saturated and the reads don't go through and the app running from /opt has a small pause/lag...

I notice this often with gpodder downloading something while I'm browsing the web with disk cache enabled. The 3 of gpodder, browser, swap hitting the emmc at the same time makes the average wait (as measured by iotop) for a request to complete easily exceed 500ms. That's noticeable latency.


On my sheevaplug I compared ext3 and nilfs2 on a OCZ Rally2 dual channel usb flash drive. It has over 20megabytes/s sequential write speed, compared to the promised 6 megabytes/sec of class 6 memory cards. The benchmark consisted of copying my 2 gigabyte squid webcache directory. ext3: 500kbyte/s nilfs2: 5000kbyte/s. A factor of 10 difference! nilfs2 is by accident and its nature faster on flash.. I hope to test LogFS some day too, it has actually been designed with flash in mind..

@SR, can you explain to me how to disable the watchdog on the device? you were saying you had considerable performance increase after disabling it?