> 
> 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.