>
> 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.
>
> > 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.
This pretty much sums up my opinion too.
If people didn't care about their data they'd just use FAT :-).
If I was to implement a less cautious policy it would be along the lines
of what Claudio says:
*) ECC errors would trigger a garbage collection cycle on the block
(copy off and erase). I would, however add a "three strikes and you're
out" extension to that to make things safer (ie. Once 3 ECC errors are
detected on a block, we'd retire the block).
*) Actual write error would cause a retirement.
(text/plain)