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

Andy Green andy at
Fri Jan 11 16:35:57 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

> - make the partition we have to scan smaller
>   - distinct partitions (Andy)
>   - initramfs

This will need unpacking / regenerating when packages want to stick
things in there, really we need most of the stuff initscripts want to
touch available quickly so this will be large too, also cause a blocking
delay while the large fs image is fetched from NAND and unpacked.

>   - overlay (Joachim, OpenWRT uses squashfs+jffs2)

Didn't find anything on Joachim in Google.  There's unionfs as well in
the overlay side, not sure it's in mainline.

> - 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.

> - do not do a linear scan of everything
>   - checkpointing (yaffs2)
>   - better data structures (LogFS)

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.

> - accelerate the speed at which we do the linear scan
>   - make NAND access faster (hwecc, DMA, readahead)
>   - skip blocks we know can't contain meta-data (*)
> - access the file system before the scan completes (*)

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, pivot the rw one on top of
the ro one when it is done?

> Anyway, there's more to examine, and I need to gather a bit more
> background data as well. I rather like the idea behind LogFS, because

Yep, thanks for the update!

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list