On Sat, 20 Oct 2018 at 08:58, Richard Weinberger <richard@xxxxxx> wrote: > Am Freitag, 19. Oktober 2018, 23:28:33 CEST schrieb Rafał Miłecki: > > On Fri, 19 Oct 2018 at 16:59, Richard Weinberger <richard@xxxxxx> wrote: > > > Am Freitag, 19. Oktober 2018, 16:45:53 CEST schrieb Richard Weinberger: > > > > Well, I fear it uncovers a problem in UBIFS. We had already problems with overlayfs. > > > > Did you bisect the problem and you are sure that the said commit is the first bad commit? > > > > > > Another thing, UBIFS has no export operations, so overlayfs will fall back to xattrs, > > > if I read the commit correctly. > > > Maybe this is the root of the problem. > > > > > > I'm currently traveling, so I cannot test much. Please make sure whether > > > 3a1e819b4e80 is really the first bad commit. > > > Then I can go for a bug hunt. :-) > > > > I did another test and everything keeps pointing to the 3a1e819b4e80. > > > > 1) I switched to the 4.12.14 > > 2) I confirmed problem exists there > > 3) I added "return 0;" at the beginning of ovl_set_origin() > > 4) I confirmed problem disappeared > > Okay. But I still think we're facing some UBIFS problem. > > To double check, on Linux 4.12.14 the problem exists and by reverting 3a1e819b4e80 (or making it a nop) > it goes away? Yes. This is exactly what I described above (4 steps test). Making ovl_set_origin() a NOP in 4.12.14 makes problem disappear. > Do you see the warning regarding the double orphan only in the bad case? No. Let me quote myself: "Please note I wrote this error appears *with* ovl commit and also with one commit earlier.". If I checkout 3a1e819b4e80~1 (one commit before) I don't see power cut corruption BUT I still see orphan error. It seems despite me explaining some things twice still not everything is clear. Let me work on a complete summary for all commits & behaviors. -- Rafał
