UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Artem Bityutskiy]

On Thu, 2012-03-29 at 15:48 +0000, Matteo Mattei wrote:
> Artem Bityutskiy <dedekind1 <at> gmail.com> writes:
> 
> > 
> > On Fri, 2012-03-16 at 17:14 +0100, Matteo Mattei wrote:
> > > Hi guys,
> > > 
> > > I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.
> > > 
> > > I already posted some requests to TI forum but I have no answers up to now:
> > > http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875
> > 
> > Well, this error was reported several times. AFAIR, there are 2 possible
> > causes for this.
> > 
> > 1. Your driver does not protect the empty space. Normally the driver
> > corrects bit-flips using ECC, but some systems do not do this for empty
> > space, i.e., for the flash regions which have been erased but have never
> > been written. UBIFS expects to see all 0xFFs there, and if it doesn't,
> > it reports about corrupt empty space.
> > 
> > You can fix this by fixing the driver, at least this is what people seem
> > to do. If this is impossible to fix, you can teach UBIFS to tolerate
> > bit-flips in the empty space.
> > 
> > 2. More difficult issue which no one still dares to start fixing is the
> > unstable bits issue. I do not have time to work on this, so I offer
> > everyone assistance, but no on so far started working on this, AFAIK.
> > Here is the description of the issue:
> > 
> > http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits
> > 
> > HTH.
> > 
> 
> Hi Aartem,
> I have some updates (also a BCH fix) as reported here:
> http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx
> 
> Anyway the read-only mounting persists.
> I have errors also at run time (without power cuts) simply performing very 
> frequent and stressful reading/writing operations (using dd and md5sum with 8 
> parallel processes).

Does BCH in your tree protects the free space? CCing Ivan, just in case.
Preserving more than usual of the context for him.

> 
> At this point I am wondering:
> 1- Is possibile that the "unstable bits" issue happens also during run-time 
> simply reading and writing?

Not as far as I know.

> 2- How can I do to tolerate bit-flips in the empty space?

Make your ECC protect it. Or modify UBIFS and make it tolerate bit-flips
in empty space. I think in the newest kernels we export the ecc strength
in 'struct mtd_info', and it could be used when scanning the empty
space. But I am not so sure this is a good idea.

> This is the output of dmesg during heavy reading/writing operations (as 
> described above):
> 
> UBIFS error (pid 2289): ubifs_scanned_corruption: corruption at LEB 6182:126342
> 00000000: fffffffd ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000040: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000060: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000080: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000000a0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000000c0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000000e0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000100: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000120: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000140: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000160: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000180: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000001a0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000001c0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000001e0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000200: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000220: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000240: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff                    ..........................
> UBIFS error (pid 2289): ubifs_scan: LEB 6182 scanning failed
> UBIFS warning (pid 2289): ubifs_ro_mode: switched to read-only mode, error -117
> UBIFS error (pid 2289): make_reservation: cannot reserve 4144 bytes in jhead 2, 
> error -117
> UBIFS error (pid 2289): do_writepage: cannot write page 1392 of inode 17869, 
> error -117
> 
> 
> As you can see we read fffffffd instead of ffffffff.
> 
> Thanks for your time.


-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120413/0c095ae0/attachment-0001.sig>