From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlev Zundel Date: Wed, 13 Apr 2011 16:27:23 +0200 Subject: [U-Boot] [PATCH] JFFS2: accelerate scanning. In-Reply-To: (Baidu Liu's message of "Wed, 13 Apr 2011 21:39:07 +0800") References: Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Baidu, >>> diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c >>> index dfb1745..f38f755 100644 >>> --- a/fs/jffs2/jffs2_1pass.c >>> +++ b/fs/jffs2/jffs2_1pass.c >>> @@ -1441,7 +1441,7 @@ dump_dirents(struct b_lists *pL) >>> } >>> #endif >>> >>> -#define DEFAULT_EMPTY_SCAN_SIZE 4096 >>> +#define DEFAULT_EMPTY_SCAN_SIZE 1024 >> >> Hm, this is not mentioned in the commit log. So is this detection >> already there and you simply decrease the amount of empty space you are >> looking for? >> > > 1KB FF is enough to get the conclusion that the erase block is empty. > I refer kenel to do this change Ah, so this is in the kernel, right? If I look into 'fs/jffs2/scan.c' I see that this constant even changed to 256 in 2.6.37. We should adapt accordingly. You should also include a statement in the commit message that this change "syncs up with jffs2 in the linux kernel". This is important information. [...] >>> while (ofs < EMPTY_SCAN_SIZE(part->sector_size) && >>> *(uint32_t *)(&buf[ofs]) == 0xFFFFFFFF) >>> ofs += 4; >>> >>> - if (ofs == EMPTY_SCAN_SIZE(part->sector_size)) >>> + if (ofs == EMPTY_SCAN_SIZE(part->sector_size)) { >>> + printf("Block at 0x%08x is empty (erased)\n", sector_ofs); >> >> Hm, you add this output so lets consider what it says - wouldn't it be >> better to say "is considered to be empty"? After all, we only infer the >> emptiness in the code. >> > Yes, thanks. You description is better. The kernel does it even better :) D1(printk(KERN_DEBUG "%d bytes at start of block seems clean... assuming all clean\n", EMPTY_SCAN_SIZE(c->sector_size))); Use that please. Cheers Detlev -- WARNING: The external boundaries of India as depicted in map(s) are neither correct nor authentic. Other external boundaries as depicted in the map(s) may neither be correct nor authentic. -- Garmin MapSource manual -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de