Couldn't you create copies of the directories that you want to shadow in the ext3 partition first, before you apply unionfs? If you copy the whole directory structure (without the files) from the fast flash to the ext3 partition first, wouldn't all files stick in the ext3 partition then?

If the emmc is smart, writes within a 256k block would be fast... Problem is filesystems like ext3 sprinkle data far apart, and have layouts optimized to avoid fragmentation.

Basically filesystems designed for harddrives do all the heavy work when writing, they place various datastructures all over the harddrive in order to avoid fragmentation and so that when it comes time to read or find stuff, the data it needs is close together and not fragmented.
The idea is to take the performance hit when writing, since you'll probably read the data more than once anyway.

This on harddrives where sequential writes and reads are fast, and both random writing and random reading is slow.
On emmc, sequential writes and reads are fast. No difference there. The difference is in random writes and reads. Random writes are REALLY slow. Painfully slow. Random reads, however, are pretty fast.
Thus, the complicated and thought out optimizations that make regular filesystems fast on harddrives end up hitting the weakest point of emmc storage, hitting it hard.

The nilfs2 filesystem is almost like a gigantic journal. Data is written out mostly sequentially. Data is rarely replaced, new data is instead written, with a newer version number. This was the goal of nilfs2, to be able to jump back in the journal/log and restore the filesystem to a previous state. As it happens this ends up in nilfs2 being very slow on harddrives, because the data is all over the place when it's time to read or find data. On emmc these random reads aren't all that bad, and nilfs2 generates alot less random writes. Avoiding the biggest weakness of emmc makes it more than 10 times faster in my test.

LogFS is actually designed with flash based storage in mind, so it will be interesting to see how it performs.

There's something that (as usual) bothers me with this brainstorm item. What are the benefits of most solutions?

Some of the benefits mentioned:
- Ability to install Debian packages
- Ability to build Debian or Maemo packages

... are IMO more easily done with a Debian chroot/Maemo cloned chroot, which has more benefits:
- ability to have a build environment that is not exactly the same version as your phone environment -- SDK release 0 in chroot for maximum compatibility package building vs PR1.1 in the phone
- ability to trash busybox and install bash and coreutils
- ability to install _unmodified_ ANY Debian release binary packages in Debian chroots
- plus ability to still boot your usual runtime system if the chroot is trashed for whatever reason
... vs IMO a minor tradeoff (more memory usage as you need to load both the chroot and Maemo libc + other libraries).


In my opinion the only one that has a clear benefit is solution #2 (since it means you'd be able to reflash the base firmware without reloading the installed apps!), but then it has quite an important tradeoff: even more Debian upstream compatibility is lost. Yes, changing a package's prefix is not 1-2-3: from all the packages I've ported to Maemo, 50% had some kind of hardcoded path.
I don't mind having to do this since I can report those to upstream, and getting those fixed is always nice, so solution #2 gets my vote (even if it clearly contradicts the brainstorm subject since it actually decreases debian compatibility).


And again I mention the recent improvements in the optifier. The idea is that a developer doesn't even have to know that the autobuilder is optifying.

Also, none of the options save for #3 guarantee that end users won't get their rootfs filled somehow. Then again I'm biased somehow since I've never managed to fill mine.

@javispedro

There certainly is a good case to be made for keeping optification the way it is. If you really feel that way, make it your solution in the brainstorm!

I, personally, feel that even though chroot is a possible alternative, it would be much better if we could just install Debian packages by default. Further, if we could install standard Debian packages by default, that would in no way prevent us from still installing a chroot too, if we like to, so all your benefits of having a chroot will still be available. - Oh, and by the way, I want to trash Busybox in favour of coreutils even in the standard Maemo distro, we just need the space to do it first.

I have seen that this has been discussed a few times, but I did try and couldn't find a Brainstorm or Bugzilla about it. I am new to the Maemo community, and not quite sure how Nokia decides what is officially supported by Maemo. However, it seems to me that the Brainstorm and Bugzilla tools are the main ways of consolidating community disposition. There might be other, less formal routes that come straight from discussions in the forum, but if so I am not aware of them yet.

If Brainstorm/Bugzilla are the main routes, the fact that the issue has been discussed so much that people are getting tired of the subject must mean that it is high time to bring it to the vote, right?

The problem with this solution is that many critical files can't be symlinked. It is especially with configuration files, usual way to handle it - create a new version and replace the old one.

Symlinking of directories can help but again it can be a problem with some software and nobody knows which one exactly.

Additional (but not critical) issue - read speed of small files (usually - shell scripts in /etc or localization files in /usr/share/locale or Hildon icons or X11 fonts) initially would be degradated until it sits in kernel cache. Because that files are used pretty often in "search" mode (file-by-file) it would visibly increase an overall access time.

But, at least on Diablo, some of the bootscripts didn't work without busybox. And even on Fremantle you are limited to really old versions of Debian tooling (think Sarge/Etch), with no debconf nor any other stuff. Seriously, if you want to try to "make Maemo more Debian" you're going to have to fight much greater issues than optification (which is relatively so simple it can even be done automatically!).

This still doesn't mean optification needs to be keep as is, though, since the rootfs free space is getting lower with every firmware update, and thus the "forest of symlinks" "hard limit" is getting tighter every day (which is why I didn't add it as solution, and instead voted for #2).

Sure, but that problem is equally there for optification. Since we will have to split across two filesystems in some way - either optification or something else - we will have to tie things together with symlinks or possibly mount-binds however we do it. All I am suggesting is that we do it the other way around, so that we do the linking once, at the start, instead of doing it all the time.

Well, we need to start somewhere, right? And optification is a showstopper for almost all Debian packages (at least if you want to install more than just a few). Let's do the others when that time comes, and focus on optification for now. Even if "all" we get is a big rootfs, I would consider that a substantial improvement. :-)

I hope you know about maemo-optify-deb. Save for bugs/TODOs (which TBH are not-as-low-as-I'd-like; see jebba's auto-optification of the entire rebuilt* debian etch archive), it works on most binary packages.

* Cause if you're not rebuilding packages at all you're up for some trouble sooner or later.

Look at this - http://www.linux-mag.com/id/7378/2/

"Summary" section:

One area that FS-Cache could prove to be of future use is for caching local file systems. Currently, file systems rely on the kernel for caching data and scheduling for writing/reading to/from the storage. This caching is not directly under your control. But if a local file system can be modified to use FS-Cache then you could use a small but very fast SSD or even a Ramdisk for caching of data.

It gets off symlink problem as is as bootstrap problem.

the difference between NAND and eMMC is much smaller than the one between eMMC and hard disks.