UBIFS - ubifs_get_pnode.part.4: error -22 reading pnode

[Richard Weinberger]

Frank,

Am Dienstag, 3. April 2018, 22:26:32 CEST schrieb Frank Erdrich:
> Hello Richard,
> 
> thanks for your quick response. And sorry for writing from another 
> Mail-account, I hope that will not break the thread. Our setup at work 
> is a little bit weird and I need an admin to send messages to a mailing 
> list (disclaimer removal and stuff like that).

:-)
 
> > Frank,
> > 
> > On Tue, Apr 3, 2018 at 10:28 AM, Erdrich, Frank
> > <Frank.Erdrich at emtrion.de> wrote:
> >  > Hello,
> >  >
> >  > we are encountering an error on UBIFS that prevents mounting of a 
> > partition. Maybe one of you can tell me the directly the reason for that 
> > or can help me hunting this error down.
> > 
> > UBIFS got confused wrt. free space accounting.
> > Can you tell me more on your setup? Do you use Fastmap? fscrypt? xattr?
> 
> We use only extended attributes. fastmap and fscrypt are not used. That 
> are the kernel options we have set:
> 
> CONFIG_MTD_UBI=y
> CONFIG_MTD_UBI_WL_THRESHOLD=4096
> CONFIG_MTD_UBI_BEB_LIMIT=20
> # CONFIG_MTD_UBI_FASTMAP is not set
> # CONFIG_MTD_UBI_GLUEBI is not set
> # CONFIG_MTD_UBI_BLOCK is not set
> CONFIG_UBIFS_FS=y
> CONFIG_UBIFS_FS_ADVANCED_COMPR=y
> CONFIG_UBIFS_FS_LZO=y
> CONFIG_UBIFS_FS_ZLIB=y
> # CONFIG_UBIFS_ATIME_SUPPORT is not set

Good.

> The Flash itself is divided into three mtd partitions to get some sort 
> of separation of critical data against other data. The partition that 
> shows that error is a logging partition which is, of course, written on 
> a regular base. We are not using the sync mount option at the moment. 
> Writeback timers (for dirty data) are on default value.

Side note: Having multiple UBI instances on the same MTD is not a good idea.
Usually you want the wear leveling domain as large as possible.

> >  > I'm not deep enough in the ubifs system to completely understand what 
> > is happening here but for me it seems that there are more dirty data to 
> > write than the size of the LEB.
> >  > -> 3: free 507904 dirty 524128 flags 34 lnum 0
> >  > I've seen that the values are checked in validate_pnode() where the 
> > -EINVAL (-22) comes from. The question is, how can dirty data bigger 
> > that the LEB size?
> > 
> > Yes, this can happen. That's why UBIFS does in some cases a fixup of
> > the used/free numbers.
> > These numbers are not always updated immediately and when a power-cut
> > happens their state might be inconsistent.
> 
> I'm totally fine with that behaviour as a power-cut can happen anytime 
> in an embedded system but I would assume that the ubifs-recovery would 
> bring back the system to a operable state. Or is there an error in my 
> reasoning?

Of course UBIFS should be able to recover.
I suspect a very subtle but in UBIFS' xattr code.
Other bug reports point in that direction too.

Sadly so far I was not able to pinpoint the exact issue.
Therefore I started to review the code. So far I've found some odds but
I'm not 100% sure whether these cause the trouble you see.

> Please let me know if you need more information or if I should do 
> special testing.

Can you reproduce the issue?
If so, please retry with the attached patches.
They will not fix your already broken UBIFS but they (hopefully) will
make sure that the accounting problem will not happen again.

Can you also share me the broken UBIFS image?

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-ubifs-Orphan-xattr-inodes-too.patch
Type: text/x-patch
Size: 8220 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20180403/7262cbdd/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ubifs-Fix-synced_i_size-calculation-for-xattr-inodes.patch
Type: text/x-patch
Size: 1442 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20180403/7262cbdd/attachment-0001.bin>