From: David Daney <ddaney@avtrex.com>
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Subject: Re: mtd, mtdblock and nand ecc.
Date: Wed, 14 Apr 2004 09:49:58 -0700 [thread overview]
Message-ID: <407D6BB6.6090504@avtrex.com> (raw)
In-Reply-To: <200404141815.18987.tglx@linutronix.de>
Thomas Gleixner wrote:
>On Wednesday 14 April 2004 17:13, David Daney wrote:
>
>
>>Let me start by saying that I am not trying to cause problems, but just
>>to understand the best options...
>>
>>
>
>I was not saying, that you are causing problems :)
>
>
>
>>Thomas Gleixner wrote:
>>
>>
>>>On Wednesday 14 April 2004 16:11, David Daney wrote:
>>>
>>>
>>>>>NAND aware filesystem drivers provide their own oobsel structure and use
>>>>>the xxx_ecc functions.
>>>>>
>>>>>
>>>>I am using the cramfs on a NAND partition as my root file system.
>>>>cramfs is not NAND aware, and I cannot be running userspace programs
>>>>before mounting as it is the root file system.
>>>>
>>>>
>>>I know, but why must you use cramfs ? Why dont you use jffs2 or yaffs as
>>>your root fs. Mount it r/o, so you have no hassle at all.
>>>
>>>
>>With my NAND drivers, booting the linux kernel and mounting a minimal
>>root file system on a 16MB flash takes 1:08 for yaffs and 1:25 for
>>jffs2. Using cramfs it boots in under 0:10.
>>
>>
>
>He ? 1 minute ? Where is the time spent ?
>
How should I know?
>Thats totaly out of the usual time. My boot time with JFFS2 is well below 30s
>on an ARM7. I have no YAFFS root fs handy, but it is much faster.
>
>The solution is checking where the time is lost and fixing it.
>
>
I have a custom nand driver (based on nand.c, but adapted to a non
standard nand physical interface) that uses software ECC. On a 300 MHz
mips32 cpu.
When ever jffs2 or yaffs are mounted, they both seem to read many
pages. Perhaps the ECC overhead of reading all that data.
I suppose I could turn off ECC and see how fast it is...
>
>
>>That is why I am thinking about using a non NAND aware file system for
>>things that can be read-only.
>>
>>
>
>But this does not answer my question how you want to deal with bad blocks ?
>
>
I want a file system very much like cramfs, but that can have holes in
it so that it works on NAND.
When mounted it would start scanning blocks starting from the beginning
of the NAND partition until it found a valid superblock (or what ever
you would call it). Then it would be done because all of the indexes
would be built to work around the bad blocks. Since this filesystem
would be read-only with a static structure, you would never have to read
more than necessary.
David Daney
next prev parent reply other threads:[~2004-04-14 16:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-14 4:37 mtd, mtdblock and nand ecc David Daney
2004-04-14 12:43 ` Thomas Gleixner
2004-04-14 14:11 ` David Daney
2004-04-14 14:48 ` Thomas Gleixner
2004-04-14 15:13 ` David Daney
2004-04-14 16:15 ` Thomas Gleixner
2004-04-14 16:49 ` David Daney [this message]
2004-04-14 17:36 ` Thomas Gleixner
2004-04-14 18:39 ` David Daney
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=407D6BB6.6090504@avtrex.com \
--to=ddaney@avtrex.com \
--cc=linux-mtd@lists.infradead.org \
--cc=tglx@linutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox