UBIFS corruption after power cut - possibly unstable bits issue?

Richard Weinberger richard at nod.at
Mon Oct 26 14:41:31 PDT 2015


Tim,

Am 26.10.2015 um 21:31 schrieb Tim Harvey:
> What would be causing the bit-flips on the erased pages? Could it have
> something to do with the larger flash part having a much longer erase
> time?

According to NAND manufactures can happen also on empty space.
At the time when UBIFS was designed this was not known nor was it observed.
These days it seems to happen on some large/cheap NANDs.

> There shouldn't be anything writing to ubifs so I'm not clear what
> caused this to occur. Note that even if I remove the /etc/fstab that
> causes root to be re-mounted read/write I always see 'UBIFS (ubi0:0):
> recovery needed' and I'm not understanding what causes that but it
> makes me think that NAND is getting touched each and every boot by the
> recovery process.
> 
>> In March there was an attempt to fix that in software.
>> But no mainline ready solution was presented so far:
>> http://lists.infradead.org/pipermail/linux-mtd/2014-March/052521.html
>>
>> It is not clear whether to implement this directly in gpmi-nand or MTD core.
>> Currently UBIFS assumes that empty spaces must contain only 0xff octets.
>> A naive approach would be removing that check from UBIFS, bit this can have
>> disastrous consequences as UBIFS's recovery algorithm relies on that.
> 
> I think I ran across that approach right before the thread you pointed
> me to: http://thread.gmane.org/gmane.linux.drivers.mtd/52208

:-)

> the second case is not permanent corruption - when the system is
> power-cycled it comes up fine the next time.

Yeah, but have you checked how the temporary corruption looks like?

Thanks,
//richard



More information about the linux-mtd mailing list