(NAND) JFFS2 mount time

Ferenc Havasi havasi at inf.u-szeged.hu
Tue Jun 15 02:52:02 EDT 2004

Hello Artem,

> Are your ideas about decreasing mount time secret? I'm also
> trying to optimize it a bit. Its interesting what way did you choose

No secret. (I hope your one is also no secret, so we may contiue this
conversation on this mailing list) I found some previos conversation about
it in the archives, too...

About our idea/plan: we would like to modify the mkfs and umount porcess
to store some extra information (inode_cache). At booting time it is
enough to read this information to serve the read requests, and the full
scan process can be done in the background. Write requestes should be
blocked until this background process finished. If I am right handeld
devices (but at least the Familiar distribution) uses RAM filesystem for
/tmp and /var, so the boot process hopefully does not require write

Certainly, if this information cannot be found or not valid (there was no
umount) the original slow full scan method should be processed.

One possible idea to store this information can be to introduce new types
of node (with JFFS2_FEATURE_RWCOMPAT_DELETE bitmask). One type to store
the real information (inode_cache) and an other which is stored on the
first erase block and contains direct pointers to the previous kind of
nodes/its eraseblocks. (make it easy for the mount process to find them)

What are your ideas? Did you tried out them?

We did not tried this yet, but I hope it is feasable. (David?)


More information about the linux-mtd mailing list