[patch] Allow any filesystem on MTD Nand when Read Only

Pantelis Antoniou panto at intracom.gr
Thu May 6 05:39:01 EDT 2004


Srinivasu.Vaduguri at 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




More information about the linux-mtd mailing list