On 2/10/06, Claudio Lanconelli <
lanconelli.claudio@eptar.com> wrote:
> Jon Masters wrote:
> >On 2/9/06, Claudio Lanconelli <lanconelli.claudio@eptar.com> wrote:
> >>In case of ECC error fixed during read, erase the block and write it
> >>again with the same data and read verification, if the ECC still fails retire the
> >>block.
> >I think that's a bad idea. The block should be marked as bad. It's not
> >worth losing data just to save out on theorectically marking a good
> >block bad - it doesn't seem to happen in practice. I'd rather lose all
> >of the good blocks than lose any data, so would many other people.
> But if you loose ALL good blocks you loose also your data! ;-)
Sure, but that can be handled ("this device has failed") and is
unlikely to happen in practice.
> >>That's because Toshiba document says about soft errors: "This condition
> >>is cleared by a block erase".
> >Sure. But it might be indicative of a problem nonetheless.
> Is this statement based on any documentation or on your personal experience?
I don't trust datasheets or hardware vendors above my own judgement -
and that is that I'm not willing to risk losing data no matter how
many times it might imply all is ok.
> Sorry, I don't want to raise a flame war, I just want to understand
> YAFFS bad block marking policy, and if there is a better solution.
Yeah. So, I think the policy was already explained - my own views are
incidental to that and I wouldn't worry about them too much. I'm just
saying that I like to be paranoid :-)
> Excuse me for my English, it's not my natural language.
Your English is very good indeed.
Jon.
(text/plain)