xfs
[Top] [All Lists]

Re: [PATCH v3] tests/generic: test xfs log recovery metadata LSN orderin

To: Eryu Guan <eguan@xxxxxxxxxx>
Subject: Re: [PATCH v3] tests/generic: test xfs log recovery metadata LSN ordering
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 28 Sep 2016 09:44:15 +1000
Cc: Brian Foster <bfoster@xxxxxxxxxx>, fstests@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, linux-xfs@xxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160927133730.GP27776@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <1471265786-24970-1-git-send-email-bfoster@xxxxxxxxxx> <20160927131249.GA38187@xxxxxxxxxxxxxxx> <20160927133730.GP27776@xxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Sep 27, 2016 at 09:37:30PM +0800, Eryu Guan wrote:
> On Tue, Sep 27, 2016 at 09:12:49AM -0400, Brian Foster wrote:
> > On Mon, Aug 15, 2016 at 08:56:26AM -0400, Brian Foster wrote:
> > > XFS had a bug that lead to a possible out-of-order log recovery
> > > situation (e.g., replay a stale modification from the log over more
> > > recent metadata in destination buffer). This resulted in false
> > > corruption reports during log recovery and thus mount failure.
> > > 
> > > This condition is caused by system crash or filesystem shutdown shortly
> > > after a successful log recovery. Add a test to run a combined workload,
> > > fs shutdown and log recovery loop known to reproduce the problem on
> > > affected kernels.
> > > 
> > > Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
> > > ---
> > > 
> > 
> > ping
> 
> It's pending in my stage tree, because it crashes current upstream
> kernel, and Dave wants the fixes go upstream first, so the test won't
> crash the test machine and interrupt the test.
> 
> I noticed the fixes are in xfs tree for-next branch, I think we're ready
> to include this test in next fstests update.

Yup, it's good to go.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>