Re: corrupted empty space - again
Artem Bityutskiy <dedekind1 <at> gmail.com>
2013-05-15 09:58:49 GMT
On Wed, 2013-05-15 at 11:42 +0200, Michał Przepłata wrote:
> My assumption is that when UBIFS will write 2kB page to the empty space
> with bitflips, it will (right after writting) verify ECC of that data to
> be sure it is correct, and if it isn't it will write to a different LEB
> and scrub this one. That way there will be no data loss. Isn't that the
> way things are done?
No, we do not do this - it would be too ineffecient if UBIFS read
everything it just wrote. Besides, MTD layer may do some caching, and
reading may return results from a cache...
The driver can implement this functionality, though. It could then
return an error, and then UBI would have to do recovery, which is not
very fast process, because it involves moving all the data from the
faulty erasebolock somewhere else, and then torture the faulty one.
I think it is more efficient to do something in the driver on the read
path. I really do not know what would be a robust and fast solution,
though. You could check if ECC's bytes in OOB are all 0xFFs, which would
mean that the page is empty, and you need to verify the bit-flips. But
the OOB area itself may have bit-flips in the ECC positions...
But there are people in this list who are more knoledgable in the area.
I am out of MTD business for several years already and forgot a lot of
things. You just need to somehow get their attention
> > I think this is a bad idea, because this way you also ignore real
> > corruptions, instead of noticing them right away.
> On UBI homepage there is mentioned that one should write a process
> that will periodically re-read all UBI blocks, in order to not let