mount time (was Re: Fwd: Hello -- NAND/NOR Flash design for GTA02)

[Werner Almesberger]

[ Cc:s trimmed ]

Andy Green wrote:
> This will need unpacking / regenerating when packages want to stick
> things in there,

Yep, fast but ugly.

>>   - overlay (Joachim, OpenWRT uses squashfs+jffs2)
> 
> Didn't find anything on Joachim in Google.

I meant "our" Joachim, "roh". He pointed out that OpenWRT has this
squashfs+jffs2 solution that also includes an overlay mechanism.

>> - as a variation of the above, separate read-only data from read-write
>>   data - only the latter needs scanning (that's from OpenWRT again)
> 
> Hey that's pretty good, having a ro /usr is not so uncommon, we can
> mount -oremount,rw when we do a package change.

Not so quick :-) If it isn't strictly read-only, it still needs a
structure that supports scanning.

> I guess we would take a gamble if we chose LogFS, there is limited time
> to gain experience with it but I guess it can be possible.

Yep, still needs more investigation. Another candidate would be
UBIFS, which is even newer, but considerable development seems to
have happened before it was announced:
http://www.linux-mtd.infradead.org/doc/ubifs.html

> Hey what happens if you mounted the root filesystem ro, did the whole
> initscripts without a writable /?  Would it come up immediately and then
> you can start mounting rw at a mountpoint,

The problem is that, in order to find all the files stored in the
file system, jffs2 has to scan the entire Flash:
http://sources.redhat.com/jffs2/jffs2-slides-transformed.pdf

So, if I understand the logic correctly, a partial scan gives you the
following information:

- inode X encountered, deleted flag not set -> inode X exists
- inode X does not exist -> inode X not encountered OR
                            inode X encountered, deleted flag set

This isn't a consequence of being able to write at that moment, but
it's a consequence of that file system supporting writes at all.

- Werner