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