From: kevinwu <kevinwu@e28.com>
To: Ferenc Havasi <havasi@inf.u-szeged.hu>
Cc: linux-mtd@lists.infradead.org
Subject: Re: small erase block size with EBS
Date: Wed, 23 Nov 2005 09:57:33 +0800 [thread overview]
Message-ID: <1132711053.3539.25.camel@localhost.localdomain> (raw)
In-Reply-To: <438322C6.6020002@inf.u-szeged.hu>
Hi Ferenc,
I successfully mounted a 128KiB erase block size summary image on a
16KiB erase block size NAND. The mounting speed is very high. It takes
only about 0.5 second mounting on a 32MiB partition with 90% disk
full.(My cpu is ARM926 running at 201 MHz) It seems OK. The performance
is good. I modified JFFS2 source code a little.
I changed souce code in function jffs2_do_fill_super()
from:
c->sector_size = c->mtd->size;
to:
c->sector_size = 0x00020000; //erase block size of image you generated.
It does work if the jffs2 partition has no bad block.
If there is a bad block, it will get error imformation. But I will fix
this bug soon. I know what happend.
在 2005-11-22二的 14:53 +0100,Ferenc Havasi写道:
> Hi,
>
> > I have a NAND flash with a small erase block(16KiB)
> > When I use sumtool, I find that the summary image size is much larger
> > than the original one if I use option --eraseblock=0x4000.
> > But When I use option --eraseblock=0x20000, The summary image is a bit
> > larger than the original one.
> > EBS fits for large erase block as far as I know.
> > That is to say, I can not use EBS if the NAND erase block is small. What
> > a pitty!
> > Is there any way to use EBS on a small erase block size NAND?
>
> EBS should work on your system but if the erase block size is small it
> may be not too usefull. Generally if you use bigger erase block size the
> speedup will be greater and the "used place penalty" will be smaller.
>
> So I suggest to test it: measure the rete of speedup and the difference
> in image size on your system, and you can decide it is OK for you or not.
>
> > What about CS?
>
> CS doesn't depend on erase block size as EBS does, so you may try it.
> The code of CS is more then one mouth old, so you should use it with
> earlier mtd snapshot. If you can wait a little we will update it at the
> first week of december.
It seems a better choise. I will try it.
Thanks for your information.
--
Best Regards
Kevin Wu
System Software Engineer, E28.com
Office: 86-21-23060088-352
prev parent reply other threads:[~2005-11-23 2:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-22 1:50 small erase block size with EBS kevinwu
2005-11-22 13:53 ` Ferenc Havasi
2005-11-23 1:57 ` kevinwu [this message]
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=1132711053.3539.25.camel@localhost.localdomain \
--to=kevinwu@e28.com \
--cc=havasi@inf.u-szeged.hu \
--cc=linux-mtd@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox