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 12:39:01 +0300 [thread overview]
Message-ID: <409A07B5.5050004@intracom.gr> (raw)
In-Reply-To: <AEB09EDA2548094C81ED6AA93269F63D01D09323@siebe001.apac.nokia.com>
Srinivasu.Vaduguri@nokia.com wrote:
>>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?
>>
>
>I haven't counted the number of times. But I remember reading some information,
>that even on multiple reads we do get bit errors and it is a symptom that the block
>slowly becoming bad after some time.
>
>
This is most disturbing if true.
Could you please hunt it down and sent me a link?
>>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.
>>
>
>Yes, If verify fails we have to mark it bad.
>
>But what I feel is, a read-only filesystem like cramfs is not that reliable on NAND flash.
>We have to detect a bad block early.
>
>
If the device slowly degrades when just read it's a major problem IMHO.
We could do borderline block migration before all is lost.
However I don't think that the problem is that bad.
I believe that this behaviour only occurs on heavily written blocks.
When you have a partition that is read-only by definition you're going
to write to it very few times it's very unlikely that you will run into
this problem.
I'm not familiar with JFFS2. What do we do when something like this
happens?
>Please comment if I am not right.
>
I would comment even if you were wrong ;)
>
>regards,
>Srini
>
>
>
>
>
>
>
Regards
Pantelis
next parent reply other threads:[~2004-05-06 9:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AEB09EDA2548094C81ED6AA93269F63D01D09323@siebe001.apac.nokia.com>
2004-05-06 9:39 ` Pantelis Antoniou [this message]
2004-05-06 9:48 ` [patch] Allow any filesystem on MTD Nand when Read Only Thomas Gleixner
2004-05-06 9:45 ` Pantelis Antoniou
[not found] <AEB09EDA2548094C81ED6AA93269F63D01D09322@siebe001.apac.nokia.com>
2004-05-06 7:20 ` Pantelis Antoniou
2004-05-06 8:02 ` Thomas Gleixner
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=409A07B5.5050004@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