On Fri, 19 Oct 2018 at 14:31, Rafał Miłecki <zajec5@xxxxxxxxx> wrote: > Since OpenWrt switch from kernel 4.9 to 4.14 users started randomly > reporting file system corruptions. OpenWrt uses overlay(fs) with > squashfs as lowerdir and ubifs as upperdir. Russell managed to isolate > & describe test case for reproducing corruption when doing a power cut > after first boot. > > (...) > > Can I ask you to check if there is something possibly wrong with the > above ovl commit? Or does it expose some problem with the ubifs? Or > maybe the whole UBI? > > FWIW testing above commit (and one before it) always results in single > error in the kernel log: > [ 14.250184] UBIFS error (ubi0:1 pid 637): ubifs_add_orphan: orphaned twice > > That UBIFS error doesn't occur with 4.12.14. Unfortunately it's > impossible to cleanly revert 3a1e819b4e80 from the top of 4.12.14. Let me provide a summary of all relevant commits & tests: By "Corruption" I mean file system corruption after power cut By "UBIFS error" I mean: [ 14.308125] UBIFS error (ubi0:1 pid 628): ubifs_add_orphan: orphaned twice 1) 3a1e819b4e80~1 (one commit before regression) Corruption: NO UBIFS error: YES 2) 3a1e819b4e80~1 + cherry-pick of 32fe905c17f0 (one commit before regression + ubifs fix) Corruption: NO UBIFS error: NO 3) 3a1e819b4e80 (regressing commit) Corruption: YES UBIFS error: YES 4) 3a1e819b4e80 + cherry-pick of 32fe905c17f0 (regressing commit + ubifs fix) Corruption: YES UBIFS error: NO 5) 4.12.14 Corruption: YES UBIFS error: NO 6) 4.12.14 + ovl_set_origin() made nop Corruption: NO UBIFS error: NO It proves that: 1) UBIFS error is not related to this file system corruption and can be ignored 2) 3a1e819b4e80 and ovl_set_origin() are definitely responsible for the regression and file system corruption -- Rafał