Re: Regression in handling power cuts since 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?
Do you see the warning regarding the double orphan only in the bad case?

Thanks,
//richard





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux