Re: JFFS2 problems

On Fri, 20 February 2004 20:13:35 +0900, Shuichi Mitarai wrote:
> 
> *** 1. Mount time ***
> 	<problem>
> 	- It's important for Consumer Electric Appliances to
> 	  reduce boot time. Mount time is one of them. JFFS2
> 	  spends a lot of time, because of scanning these
> 	  all partitions.
> 
> 	<sujestion>
> 	+ To avoid scanning all partitions, all data which
> 	  are related to JFFS2 on RAM are backuped to ROM
> 	  only when the OS halted correctly. Otherwise, when
> 	  the OS halted unuseally, scanning all JFFS2
> 	  partitions occur, like the current JFFS2.

Makes sense to me, although you still omitted a few pieces to the
puzzle.
1. You need a fast algorithm to find the quickmount-information.
2. When the fs gets full, you cannot store that information anymore.

And maybe also this one:
3. Make sure not to corrupt the running system when quickmount stuff
and remaining filesystems disagree.  Yeah, this is unlikely to happen
for the usual CE gadget.

> *** 2. GC algorithm ***
> 	<problem>
> 	- The block which will be garbage collected, depends
> 	  on probability, which is defined by
> 	  jffs2_find_gc_block(), like following.
> 		<probability>		<selected list>
> 		50/128			erasable_list
> 		60/128			very_dirty_list
> 		16/128			dirty_list
> 		otherwise		clean_list
> 					dirty_list
> 					    ...
> 	  If erasable_list, very_dirty_list and dirty_list
> 	  are almost empty, it is difficult to get a
> 	  erasable block even if writable regions are existing
> 	  on the partition. For this case, the function almost
> 	  selects clean_list. This means the GC can't make a
> 	  erasable block and this leads the write throughput
> 	  fall.
> 
> 	<sujestion>
> 	+ I think jffs2_find_gc_block() should not touch the
> 	  clean_list. This function concentrates on
> 	  increasing erasable blocks. Rotating, like moving a
> 	  clean block to an other block, should be processed
> 	  by the init process on some other timing, for
> 	  example.

Which would slow down bootup times again.  If you want to fsck,
defragment or optimize any fs while running, you ask for trouble.  So
it would have to be done before mounting.

It might make sense to do the rotation stuff during idle time in the
gc thread, if you care about the delay when writing to the fs.  It
might also make sense to change the propabilities.  But in principle,
the current scheme makes more sense to me.

> *** 3. Difficulty of estimating the avalable size ***
> 	<problem>
> 	- It is difficult to evaluate if the specification
> 	  of a CE appliance equipment is sufficient, because
> 	  writing size is different case by case , although
> 	  same contents files are written to a JFFS2
> 	  partition. This is caused by following reasons.
> 	  # All nodes include inode information and we
> 	    can't care about how many nodes are made. We
> 	    can't estimate how many same inodes are needed
> 	    in the ROM, because the number of nodes for the
> 	    file can't be predicted.
> 	  # If we have situations like overwriting files
> 	    partially, overlapped region is created between
> 	    the previous node and the new node. The region
> 	    of the previous node can't be used as a writable
> 	    region, because that node is not completely
> 	    obsolete.
> 
> 	<suggestion>
> 	+ Node size is defined constantly, for example 512B.
> 	  So we don't need to care about obsolete nodes,
> 	  don't need fraglist struct and we can estimate the
> 	  size we need when a data is written.

Interesting.  Might be a really smart idea, might cause tons of
problems.  My guess is this would makes many things simpler, but there
is no way to remain compatibility - which you propably don't care much
about.

Jörn

-- 
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity.
-- W. A. Wulf 

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to [email protected]