From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] JFFS2: accelerate scanning.
Date: Wed, 13 Apr 2011 16:27:23 +0200 [thread overview]
Message-ID: <m2ipui8bw4.fsf@ohwell.denx.de> (raw)
In-Reply-To: <BANLkTik+N9F+oRM-nrfC0BBcjbBvuqjbUA@mail.gmail.com> (Baidu Liu's message of "Wed, 13 Apr 2011 21:39:07 +0800")
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
next prev parent reply other threads:[~2011-04-13 14:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-13 13:39 [U-Boot] [PATCH] JFFS2: accelerate scanning Baidu Liu
2011-04-13 14:27 ` Detlev Zundel [this message]
2011-04-13 14:40 ` Joakim Tjernlund
-- strict thread matches above, loose matches on Subject: below --
2011-04-11 13:35 Leo Liu
2011-04-13 11:31 ` Detlev Zundel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2ipui8bw4.fsf@ohwell.denx.de \
--to=dzu@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.