From: Pantelis Antoniou <panto@intracom.gr>
To: Srinivasu.Vaduguri@nokia.com
Cc: dwmw2@infradead.org
Cc: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Cc: ddaney@avtrex.com
Subject: Re: [patch] Allow any filesystem on MTD Nand when Read Only
Date: Thu, 06 May 2004 10:20:25 +0300 [thread overview]
Message-ID: <4099E739.4070803@intracom.gr> (raw)
In-Reply-To: <AEB09EDA2548094C81ED6AA93269F63D01D09322@siebe001.apac.nokia.com>
Srinivasu.Vaduguri@nokia.com wrote:
>>It's pretty reasonable assumption that bad blocks are created only when
>>writting to NAND. So in the read-only case it is possible to skip over
>>the bad
>>blocks and offer a bad-block free block device to the upper layers.
>>This allows us to utilize any filesystem when read-only.
>>
>>
>
>I had seen in the past that there can be bit errors (more than one bit) when we do
>multiple reads (probably many) on the same block. So we will read corrupted data from NAND flash and we will not be able to decompress the data when using the CRAMFS. If we erase the block and rewrite the data, it works fine. This is my experience with a samsung NAND flash.
>
>So using this above logic how will we detect if there are more than one bit errors while reading. Can we afford to rewrite the cramfs image again onto the NAND flash ?
>
>Please tell me if I got this problem because of any obvious mistake.
>
>
Hmm, that's the first time I've heard about this problem.
But if you have read errors, how can you be sure that you will be able
to read the
block and write it somewhere else?
Maybe you can do something when writting your filesystem image when you
detect
a simple bit error you can immediately mark the block bad.
How many times have you written the block in order for something like
this to occur?
It seems to me that when you have a read only partition the solution is
to be
carefull when writting your filesystem image.
First you avoid the bad block altogether, and secondly you always bit verify
the block. If the verify fails you immediately mark the block as bad and
move
on.
I don't think that nandwrite does it though.
>regards,
>Srini
>
>
>
>
>
>
Regards
Pantelis
next parent reply other threads:[~2004-05-06 7:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AEB09EDA2548094C81ED6AA93269F63D01D09322@siebe001.apac.nokia.com>
2004-05-06 7:20 ` Pantelis Antoniou [this message]
2004-05-06 8:02 ` [patch] Allow any filesystem on MTD Nand when Read Only Thomas Gleixner
[not found] <AEB09EDA2548094C81ED6AA93269F63D01D09323@siebe001.apac.nokia.com>
2004-05-06 9:39 ` Pantelis Antoniou
2004-05-06 9:48 ` Thomas Gleixner
2004-05-06 9:45 ` Pantelis Antoniou
2004-05-05 12:33 Pantelis Antoniou
2004-05-05 12:57 ` David Woodhouse
2004-05-05 13:03 ` Pantelis Antoniou
2004-05-05 15:26 ` David Daney
2004-05-05 17:44 ` Phillip Lougher
2004-05-05 19:07 ` David Daney
2004-05-06 7:12 ` Pantelis Antoniou
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=4099E739.4070803@intracom.gr \
--to=panto@intracom.gr \
--cc=Srinivasu.Vaduguri@nokia.com \
--cc=dwmw2@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