(posting some ideas that came out of some internal discussions last week)

mini_fo
The mini_fo is a small (96k) filesystem overlay module that combines two filesystems into a new virtual filesystem. This would replace the current method of symlinking the jffs2 partition to squashfs, which currenly takes around 350k of space on the jffs2 partition. The net effect is the following:
/ (mini_fo)
/rom (squashfs)
/jffs (jffs2)
The jffs2 filesystem will only contain files that have changed from the squashfs counterparts; no more symlinks. Note: mini_fo will not check if the new file is identical to the squashfs file; there needs to be a mechanism to correct this.

A partial set of patches: http://downloads.openwrt.org/people/mbm/mini_fo.patch

Backing up jffs2
The squashfs images contain a "dirty flag" in the firmware images which trigger an automatic reformatting of the jffs2 filesystem; this is done to ensure filesystem integrity after an upgrade since the jffs2 filesystem resides immediately after squashfs and may become corrupted or otherwise invalidated by the upgrade process. (partially overwritten by a larger squashfs, missing or broken symlinks due to squashfs changes, config files in old formats nolonger usable by the current set of applications)

Prior to erasing the jffs2 partition, we can attempt to mount it and dump any data we find onto a ramdisk/tmpfs. The data recovered may be incomplete, obsolete or corrupted by the reflashing process, so it's unlikely that we would simply write the data back to the jffs2 partition after reformatting it, but preserving the data and making it available to the user may become part of a last ditch effort for users who didn't read the upgrade warnings in the manual.

Sounds like an execellent step forward to me.

Cheers!

Is there allready anything ready to play with, because i am very interested in using mini_fo? (I am especially interested in a patch that adds support for mini_fo to the kernel, i do not need a ready integration into OpenWRT atm.)

mini_fo:

This sounds really good to me as well, sounds like the logical next step to improve system ease of use and compatability...

backing up the jffs2:

I would be interested in making the jffs2 backup available for retreival before flashing the system.  It could be used as a reference for configuring a freshly upgraded installation...

Mini_fo is definitely a big step in right direction. No more vi editing of ro config files ;-)

mbm: Are you sure that ramoverlay stuff is still usefull? Clearing of <1MB jffs partition (4MB flash - big squashfs) seems to be pretty fast. I have no idea how it goes on 8MB device with standard squashfs... I would go for simplier boot without second stage (sorry :-)

What the hell 350k? That must be a 6megs squashfs if there is 350k symlinks 8-O
I'm sure you know symlinking of normal image needs approx 100kb in jffs2 and the rest to those 350k (2 or 4 erase blocks) is jffs2 overhead - and it'll stay there even with mini_fo. Just to be precise and not give false hope: mini_fo will not save much of flash (I guess cca 50k)

Backing up jffs: seems unlikely that

would find some backup in tmp before he reboots. I'm afraid that it could screw up boot on devs with small RAM.

A proposal (unacceptable for you mbm, I'm affraid):
Check OpenWrt partition for gzip magic before mounting jffs2 and if present ungzip untar raw partition to /tmp/root and use it as mini_fo storage directory.
And use /tmp/root also if there is not enough space for jffs2. It's just a couple of lines and they would do miracles on 2MB flash devices... (saving cca 256k of jffs2 overhead)

About mini_fo: amazing. Please, go ahead. (I had a look at mini_fo code for the file check problem you mentioned, but it is far from my skills)

About the backup I agree with Netprince:

As I'm thinking about custom images and/or a few spare ram remaining after custom apps loaded on boot... they could leave no room for the backup (and creating troubles?).
Users that don't read the README files are the same that come on the irc channel asking for support that is already available on the first page of the wiki... these users can make a backup before flashing, better if the backup feature is available trough the webif (simpler and most effective: no risk to have corrupted data). IMHO

ciao

Wallace

i agree that backing up from the webif is probably the best route for saving users. However, there still is the problem that, typically, those standard backup scripts are written for environments where everything is input via the webif. That makes it easy to backup the config. I've been trying to figure out a way to backup all files that will get written over and that we want to keep and send directly to an external source (so inadequate space on the router isn't a problem), but haven't gotten all the way there. My hope is to just have a list of parameters at the top, and that will take care of everything.

is mini_fo like unionfs, only mini?

To my experimence mini_fo is somewhat unreliable. Especially when deleting files. Have seen once a vanishing directory, partly repaired by a reboot. May or may not caused by optimization - kicked off all ASSERT()s / kprint()s for unbloating. For this reason, I recommend an nvram option for old-style-symlinks in preinit.

As for the TFTP-Reflash-Detection. Talked once to nbd about this. Want to offer the squashfs for (re-)download via web UI - but this feature changes the CRC. nbd says there is an unused bit in the trx header worth investigation as a better place for this flag. Also: I don't think a backup feature for the jffs2 is really necessary. If someone does a TFTP upload (s)he *wants* the thing clean. Flashing with web UI may be protected by a dialog stating 'Enter "Yes I have a backup" to flash'.

It's not a "reflash-detection", it's simply dumping the contents of jffs2 to ram before wiping the partition.

What the heck were you talking about?

About /sbin/mount_root::is_dirty() aka. is_clean()

Again, what the heck are you talking about?

How will mini_fo interact with safe mode boot?

About wget http://192.168.1.1/cgi-bin-fw.trx with a simple cgi like this:
echo Content-type: bla/blubb
cat /dev/mtd/1ro

Is there a reason that openwrt is not ready to be exclusively jffs2 based (no squashfs)? Wouldn't that solve both these problems?

I don't want the core OS in jffs2. I want it read-only in squashfs, with a safe-mode check before it makes use of any of the read/write areas.

The combination of squashfs and jffs2 is perfect for this and if mini_fo works well enough to use at some stage in the boot process with pivot_root or similar, to make the root filesystem appear read/write then I'm happy.

The option of making a backup of only the things that were changed via mini_fo would be very welcome. Something like a tar file available for download with webif would be nice.

is the reason you want the ro squash is to be protected from damaging the core fs and not being able to boot? i understand this, but i think a fully jffs that you can backup, uninstall pre-installed packages, and upgrade from version to version would be REALLY nice. (note to devs: not complaining about the lack of this, just saying, something like apt-get upgrade from version to version would be cool as hell)

SquashFS also has a large compression advantage over JFFS2.  While this may not be much of an issue on 8MB and USB capable routers, on 4MB flash routers this makes a huge difference. With the default RC5 SquashFS image, w/ NAS, OpenSwan, OpenNTPd, and TCPDump tacked on, the packages and dependancies leave me with ~300KB free on the JFFS2 partition on a WRT54G.  With a pure JFFS2 filesystem I would not be able to have all of these packages.  Once I flash my customized WhiteRussian SVN image over with all those packages in the SquashFS partition, and mini_fo enabled, I should see a large increase in free space.

(Last edited by Bartman007 on 27 Apr 2006, 07:55)