JFFS2 - speed up while booting

Darwin Rambo drambo at broadcom.com
Tue Jan 5 11:17:11 EST 2010


 
> It can take a few minutes to complete the erase procedure 
> though; if you do a 'top' on your system you'll see the pdflush task at 
> the top while it is in progress, so if you reboot your system several 
> times in succession JFFS2 might not have time to complete the erase of all 
> unused blocks.

This pdflush activity can take much longer on very large flash parts and be
almost unnoticable on small devices. The reboot command in busybox (and any 
command that tries to flush data to flash) is also stalled until this operation 
is complete. You might think the system is hung at this point but it isn't.

This is the typical erase cycle for one block:

Starting erase of pending block 0x1b200000
Freeing all node refs for eraseblock offset 0x1b200000
jffs2_erase_block(): erase block 0x1b200000 (range 0x1b200000-0x1b280000)
Erase completed successfully at 0x1b200000
Verifying erase at 0x1b200000
Writing erased marker to block at 0x1b200000


The real reason for the long delay is not the erase time, but the time to 
validate that the erase actually worked and that all the data is 0xff. 
If you comment out the jffs2_block_check_erase function below
as shown, then in my case, the 4.5 minute pdflush delay dropped to 2-3 
seconds! I was using a 16Gbit large page flash for this test.

static void jffs2_mark_erased_block(struct jffs2_sb_info *c, struct jffs2_eraseblock *jeb)
{
	size_t retlen;
	int ret;
	uint32_t uninitialized_var(bad_offset);

#if 0
	switch (jffs2_block_check_erase(c, jeb, &bad_offset)) {
	case -EAGAIN:	goto refile;
	case -EIO:	goto filebad;
	}
#endif


Darwin


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/





More information about the linux-mtd mailing list