Re: [backport request][stable] xfs: xfstests generic/538 failed on xfs

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

 



On Sat, Jun 29, 2019 at 10:41:35AM +0300, Amir Goldstein wrote:
> On Sat, Jun 29, 2019 at 12:50 AM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
> >
> > On Fri, Jun 28, 2019 at 07:46:34AM +0300, Amir Goldstein wrote:
> > > On Fri, Jun 28, 2019 at 12:35 AM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
> > > >
> > > > On Thu, Jun 27, 2019 at 07:18:40PM +0300, Amir Goldstein wrote:
> > > > > On Thu, Jun 27, 2019 at 6:55 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
> > > > > >
> > > > > > On Thu, Jun 27, 2019 at 08:10:56PM +0800, Alvin Zheng wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > >     I  was using kernel v4.19.y and found that it cannot pass the
> > > > > > > generic/538 due to data corruption. I notice that upstream has fix this
> > > > > > > issue with commit 2032a8a27b5cc0f578d37fa16fa2494b80a0d00a. Will v4.19.y
> > > > > > > backport this patch?
> > > > > >
> > > > > > Hey Alvin,
> > > > > >
> > > > > > Thanks for Bringing this to attention.  I'll look into this a bit more.
> > > > > > Time for a new set of stable fixes for v4.19.y. Of course, I welcome
> > > > > > Briant's feedback, but if he's busy I'll still look into it.
> > > > > >
> > > > >
> > > > > FWIW, I tested -g quick on xfs with reflink=1,rmapbt=1 and did not
> > > > > observe any regressions from v4.19.55.
> > > >
> > > > As you may recall I test all agreed upon configurations. Just one is not
> > > > enough.
> > >
> > > Of course. It's just a heads up that testing looks sane so far.
> > >
> > > >
> > > > > Luis, sorry I forgot to CC you on a request I just sent to consider 4 xfs
> > > > > patches for stable to fix generic/529 and generic/530:
> > > > >
> > > > > 3b50086f0c0d xfs: don't overflow xattr listent buffer
> > > > > e1f6ca113815 xfs: rename m_inotbt_nores to m_finobt_nores
> > > > > 15a268d9f263 xfs: reserve blocks for ifree transaction during log recovery
> > > > > c4a6bf7f6cc7 xfs: don't ever put nlink > 0 inodes on the unlinked list
> > > > >
> > > > > If you can run those patches through your setup that would be great.
> > > >
> > > > Sure, it may take 1-2 weeks, just a heads up. If you're OK with waiting
> > > > then great. Otherwise I personally cannot vouch for them. What types of
> > > > tests did you run and what configurations?
> > > >
> > >
> > > So far I tested, -g quick with reflink=1,rmapbt=1.
> 
> FYI, -g auto found no regression with reflink=1,rmapbt=1.
> 
> > >
> > > Sasha wrote that more results will be in tomorrow...
> >
> > I'd rather be cautious, how about we wait until I also confirm
> > no regressions as well. In this case since we already have candidates
> > you identified, and Darrick vouchces for, I can just jump start the
> > process and deal with both manually reviewing each of these changes
> > and also confirming no regressions are in place on my tests as well.
> >
> > Then we'd have at least 3 XFS pair of eyeballs reviewing and at least
> > 2 full independent tests vouching for these.
> >
> 
> Sure, that'd be great. How long does your full run take?

Not long, its just I wanted to also add xunit processing support onto
oscheck as well. I'll start on that now, hopefully it'll all be done
and tested by end of next week.

  Luis



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux