[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: your mail



On Tue, 9 September 2003 08:44:21 -0500, J B wrote:
> 
> A jffs2 internals question for the masses:
> 
> Besides the 128Kb max kmalloc issue, is there any restriction on the size 
> of an eraseblock that jffs2 can use?
> 
> I am using the slram driver with a 4Kb eraseblock size to create a 4Mb ram 
> device.  I mount jffs2 on top of this and everything appears to work until 
> the filesystem becomes full.  I try removing a file and the remove command 
> returns "rm: cannot unlink `foo' : No space left on device".  df reports 
> 100% usage.
> 
> Also, looking at the output from having CONFIG_JFFS2_FS_DEBUG=1, it appears 
> that garbage collection is constantly running and picking blocks from the 
> clean list because there are none on the dirty list.  Eventually even this 
> fails and the garbage collector loops and complains repeatedly:
> 
> "Argh. No free space left for GC.  nr_erasing_blocks is 0.  nr_free_blocks 
> is 0. (erasingempty: yes, erasependingempty: yes)
> jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28"
> 
> The thread_should_wake is returning 1 because the dirty size is > an 
> eraseblock, so it loops forever.
> 
> If I switch the eraseblock size in slram back to 64Kb, this problem does 
> not appear.  So again, are there any restricitons on how small of an 
> eraseblock size you can use, or is this something that hasn't ever really 
> been an issue?

Not completely unexpected.  I've always disliked the 5-eraseblock
number and started a discussion with David on the mtd list some time
ago.  For some reason, other matters occupied our minds so this was
unfinished.  But it is still in the archives.

The problem is that jffs2 doesn't need 5 eraseblocks, but rather 2 +
number_of_eraseblocks / some_constant.  So with 1024 eraseblocks, you
appear to need more than 5 (empirically proven :), while with 64
eraseblocks, you could get away with 5.  Maybe not, but there are very
few (no) bug reports, so it should be safe.

What jffs2 needs is to get rid of the constants for
JFFS2_RESERVED_BLOCKS_* and make them superblock variables instead.
Then we have to calculate them during mount time using some formula.
A patch doing the first step should still be in the archives, in the
same thread as the discussion or nearby.

Hope that helps!

Jörn

-- 
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com