I initially discovered Switchfin from this page. It criticises Switchfin for wasting 20MB of RAM on creating a copy of the root filesystem, while BAPS uses the NAND directly. I, too, thought this approach seemed a little strange and I've been thinking about it for a while.

I gather that this was done to prevent wearing out the NAND but as Gilles has already pointed out here, only writes wear out the NAND. Configuration changes are written to the NAND anyway via /persistent so the only writes we are avoiding are the ones we don't need to keep, such as those in /var/run and /var/log. Why couldn't we just mount tmpfs instances over those directories?

This may not be enough though. It is important to have some way of reverting back to the default configuration, as is currently being done with /persistent/defaults.tgz. But this approach is horribly inefficient. You write a copy of defaults.tgz to the NAND even though it actually already exists elsewhere on the NAND. And then you extract all the files even though only a few might have actually changed. Additional old files are never deleted and may accumulate over time. Their presence may even cause unexpected problems. Finally, changes are restricted to files we have explicitly created symlinks for in /etc/rc.

I have some experience in a couple of different implementations of UnionFS and have found it to be extremely useful. I have since discovered mini_fo, a specialised implementation catering for embedded devices, written by the creators of U-Boot. It is much simpler than the official Linux kernel implementation but provides everything we need. Two branches, a read-only branch overlayed by a read-write branch.

The read-only branch would be the original copy of the filesystem on the NAND. The read-write branch would be a separate partition, much like /persistent is now. The difference is that only the changes would actually be written to the NAND and they could be done anywhere in a transparent fashion, negating the need for awkward symlinks. Reverting to the default configuration would simply involve deleting all the files on this partition, of which there probably wouldn't be many. You could even just delete a single file to revert the settings on a single GUI page, for example. Needless writes could still be avoided by mounting tmpfs where necessary.

I would really like the community to seriously consider this proposal. It would save a huge amount of RAM, result in fewer writes to the NAND, and would be easier to build, use and maintain. I honestly can't think of a down side! There might be a little pain for those with existing setups but this is still a young project and I'm sure the few users we have wouldn't mind in the name of progress, especially with so many positives.

Oh, and of course I'll do all the work.