UBIFS failure & stable page writes

Prins Anton (ST-CO/ENG1.1) Anton.Prins at nl.bosch.com
Wed Jun 12 03:12:34 EDT 2013


Hi Artem,

Hopefully you can find some time for some analysis on the LEB, I managed to dd LEB9.
It is attached! 

Thanks in advance,

Met vriendelijke groeten | Best Regards, 
Anton Prins

-----Original Message-----
From: Artem Bityutskiy [mailto:dedekind1 at gmail.com] 
Sent: maandag 3 juni 2013 8:01
To: Prins Anton (ST-CO/ENG1.1)
Cc: Jan Kara; Adrian Hunter; linux-mtd at lists.infradead.org
Subject: Re: UBIFS failure & stable page writes

On Fri, 2013-05-31 at 11:51 +0200, Prins Anton (ST-CO/ENG1.1) wrote:
> Hi Artem,
> 
> Some questions regarding this issue:
> - The orphan area is fixed size, in the implementation we unlink/delete a file 4 times a second... could there be any relation?
>   (How can we calculate the required orphan area size in LEBs?)

No, we stress-tested it with a lot more frequent deletions. I cannot
answer about size calculation off the top of my head, I'd need to read
the code and try calculating. But I guess it is easier to find this out
by writing a small test program which will create create/open/unlink
files until it fails. And you can experiment with amount of orphan LEBs
ans find all the numbers. You can also share them with us :-)

> - Initial the three file systems are programmed if 'flat-image' (ubinized and free space fix-up) from U-boot; can there be an issue?

There were several free space fix-up bug-fixes recently.

I wonder if you have these patches:

0c6c7fa1313fcb69cae35e34168d2e83b8da854a
fe96efc1a3c049f0a1bcd9b65e0faeb751ce5ec6

They prevent from unpleasant bugs in flashers - when you flash a new
image to a flash which alsready contains some UBI stuff, and flasher
does not erase some eraseblocks, the old contents may be treated as part
of the new image, causing really random and subtle problems.

>   (Every ubi-filesystem has its own MTD, so I guess partition separation is guaranteed by the MTD-layer).

Should be.

> - How can I find the orphan LEB(s), to send you some 'contents'?

The LEB numbers range is:

[c->orph_first, c->orph_last]

So all LEBs from c->orph_first to c->orph_last are orphan LEBs.

You can inject printk and print the numbers.

Then you can read the corresponding LEBs directly from /dev/ubiX_Y using
dd. You'll just need to calculate offsets. Offset is LEB number * LEB
size.

-- 
Best Regards,
Artem Bityutskiy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: LEB9DUMP.BIN
Type: application/octet-stream
Size: 516096 bytes
Desc: LEB9DUMP.BIN
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20130612/92bef671/attachment-0001.obj>


More information about the linux-mtd mailing list