public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Alvin Zheng <Alvin@linux.alibaba.com>,
	gregkh <gregkh@linuxfoundation.org>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	Brian Foster <bfoster@redhat.com>,
	"joseph.qi" <joseph.qi@linux.alibaba.com>,
	caspar <caspar@linux.alibaba.com>
Subject: Re: [backport request][stable] xfs: xfstests generic/538 failed on xfs
Date: Thu, 27 Jun 2019 21:35:20 +0000	[thread overview]
Message-ID: <20190627213520.GG19023@42.do-not-panic.com> (raw)
In-Reply-To: <CAOQ4uxgqgDAdKZDYwmf0M35M3D6Ctn25-VVj3wu5XSj_4c-WdA@mail.gmail.com>

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@kernel.org> 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.

> 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?

  Luis

  reply	other threads:[~2019-06-27 21:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27 12:10 [backport request][stable] xfs: xfstests generic/538 failed on xfs Alvin Zheng
2019-06-27 15:54 ` Luis Chamberlain
2019-06-27 16:18   ` Amir Goldstein
2019-06-27 21:35     ` Luis Chamberlain [this message]
2019-06-28  4:46       ` Amir Goldstein
2019-06-28 21:50         ` Luis Chamberlain
2019-06-29  7:41           ` Amir Goldstein
2019-07-02 19:34             ` Luis Chamberlain
2019-07-16 17:13               ` Luis Chamberlain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190627213520.GG19023@42.do-not-panic.com \
    --to=mcgrof@kernel.org \
    --cc=Alvin@linux.alibaba.com \
    --cc=amir73il@gmail.com \
    --cc=bfoster@redhat.com \
    --cc=caspar@linux.alibaba.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox