UBIFS Index Node Corruption - Invalid Key Type

DHANAPAL, GNANACHANDRAN (G.) gdhanapa at visteon.com
Tue May 10 07:49:03 PDT 2016


On Tue, May 10, 2016 at 03:58:58PM +0200, Richard Weinberger wrote:
> On Tue, May 10, 2016 at 2:14 PM, DHANAPAL, GNANACHANDRAN (G.)
> <gdhanapa at visteon.com> wrote:
> > Hi There,
> >
> > We have i.MX6d based platform that has FSL BSP 3.10.17 running.
> > There is SLC Micron NAND of size 2GB with 512K Block size and 4K min I/O  used
> > for software storage. This NAND has got 7 partitions, Among that two partitions
> > have Read-Write ubifs file system for runtime data and one has Read-only ubifs
> > file system that has all the system files. Recently we have observed a issue that
> > one of RW ubifs partition failed to mount due to invalid key type in one of index
> > node in ubifs. we have seen the same issue in two units out of 1000 units running
> > in the field.
> >
> > Following is the index node that has  invalid key in its first branch.
> > key type = 0xa917dd4c >> 29 = 5 (invalid key)
> >
> >         magic          0x6101831
> >         crc            0x944add59
> >         node_type      9 (indexing node)
> >         group_type     0 (no node group)
> >         sqnum          378678
> >         len            148
> >         child_cnt      6
> >         level          2
> >         Branches:
> >         0: LEB 569:280144 len 108 key (bad key type: 0x000001, 0xa917dd4c)
> >         1: LEB 446:349792 len 108 key (5595, inode)
> >         2: LEB 584:361528 len 108 key (5822, inode)
> >         3: LEB 602:255360 len 108 key (6050, inode)
> >         4: LEB 613:480280 len 188 key (6258, inode)
> >         5: LEB 614:373784 len 88 key (6521, data, 25)
> >
> > Please help us to understand following points
> >
> >         1. Did this happen because abrupt power cut ? if so, how could CRC of the node still be intact?
> >         2. Could there be any bit flip ? but still again CRC intact.
> >         3. Would the key pointed by  corrupted branch be  UBIFS_DENT_KEY or  UBIFS_XENT_KEY ?
> >                 Because  29 bit of key[0] (0xa917dd4c  & 0x1FFFFFFF) seems to have some kind of  hash value.
> >                 but node (at leb 569:280144)  that is pointed by corrupted branch seem to be index node.
> >         4. This corrupted entry is always seen  in first branch of an index node  in two failed units. Could there be reason?
> >         5. Since CRC is intact, would there be any possibility or scenario that corrupted node can be written with valid CRC?
> 
> Hmm, this looks like some UBIFS inconsistency.
> If the header CRC is correct it should be be any kind of bitflip or
> power cut issue.
> 
> Can you please share the whole UBI image (a nanddump) such that I can
> inspect it?
> 
> -- 
> Thanks,
> //richard

Thanks for the reply, Richard. 
Please find two files in google drive share.

	1. dump_mtd7_ecc.log   - /dev/mtd7 dump with ecc
	2. leb_peb_map_22706.log   - LEB to PEB map. This information is taken by having print in table.

Share:
	https://drive.google.com/open?id=0B7tYZDLZ_KAZMFd4MENlQkJuNjA

Cheers
Gnana





More information about the linux-mtd mailing list