(NAND) JFFS2 mount time
Artem B. Bityuckiy
abityuckiy at yandex.ru
Thu Jun 17 03:56:00 EDT 2004
Hello Frank. Thanks for reply.
Ferenc Havasi wrote:
> 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?)
Very short description of my idea:
I thought about introducing special node type (say, raw_blkdescr) which
should appear at the beginning of each block and describes some other
block's layout. The process of writing will be like this: we write node
on one block and simultaneously write it's description to some another
When mounting, we just scan beginnings of flash blocks and construct
inode_caches. After that we can read/write. Full scan goes in background.
I didn't try this too. More over, this is just an idea for now - I'm not
even sure that such algorithm is feasible yet.
Artem B. Bityuckiy,
More information about the linux-mtd