Hello, Sorry for the broken threading. I just subscribed and the quote is from copy- paste from nabble.
> ext Andrew Flegg <andrew at bleb.org> writes: > > > Although a unionfs solution would be a bit more further dev on Nokia's > > part, it will reduce the developer complexity and gives us a real > > world solution now. I'm sure the community would help as well, with > > patching/building/testing kernel modules (once again, Nokia should > > realise there are clever technical people in the community who could > > help design an optimal (= quick & good) solution if engaged at the > > right time). > > Yes, agreed. Let's give this unionfs thing a shot. I was previously > arguing against it, but only as a long-term solution. As a > Fremantle-only hack, it might be better than the /opt hack. After reading the whole thread I could offer you the following suggestions/thoughts: 1) /opt is not a good solution (tm). You can install large programs there (e.g. openoffice) but you should not install programs that other programs depends to there (e.g. libraries or command-line utils). This means that (according to what I understand from FHS) a program should not depend on another program in /opt. 2) You should consider making /usr/local a separate filesystem and suggest that programs use that instead of /opt. A system can work with most of its programs in /usr/local and you don't need of links, etc. I had a slackware- based system which had almost everything in /usr/local for 8+ years and there weren't any problems at all. 3) If finally you use /opt/maemo, it may be better to suggest some hashing. For example /opt/maemo/foo could be in /opt/maemo/f/foo. 4) unionfs should be a very good and clean solution. I strongly suggest that you don't use UnionFS and you use AUFS. I had a lot of problems and oopses with the former. 5) If you use aufs, it will be a bit tricky to upgrade packages that are installed in / in a consistent way. For example, apt-get upgrade could end up installing things in the other partition. To solve this you should either do a chroot somewhere else (not-good) or use some voodoo magic :-) 6) If you somehow use aufs, it is possible to speed things up a bit. For example, you could: * Create a union of the small (old) / and a X GB partition which is then mounted as / * Mount the small (old) / as /oldroot as read-only. * Prepend /oldroot/bin:/oldroot/sbin:/oldroot/usr/bin:/oldroot/usr/sbin in $PATH * Perhaps use LD_LIBRARY_PATH with /oldroot/lib:/oldroot/usr/lib first. This would make many of the things load directly from /oldroot while be able to fallback to the unionfs (which should not be that slow). Of course /usr/share won't be used directly, but I believe you can live with that. 7) I can report a success story from 5 computer labs with 120 PCs and more than 300 different students using aufs every day for two years now without a problem and AFAIK without a single kernel panic or oops. It is a little different configuration (union of a physical FS and a tmpfs) but it is a good test for AUFS. 8) You could reconsider (or explain) the need and usage of the internal memory (should I call it JFFS2 NAND?) completely. What is it's purpose? Clearly, it is not fit for the / filesystem if N900 is going to be used in a standard unix-way with non-nokia programs and upgrades. 9) If you need this memory to just be able to provide "re-flash" updates/upgrades, then I cannot find a reasonable way to make this work without problems. Upgrading a library in /usr/lib (for example) could break programs. apt and dpkg are far better in handling this. However, this could always act as a fall-back solution (fail-safe), in case something breaks with the other memory. 10) If you want to use this memory for speed-up, then I believe there are a number of ways to do it. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
