All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] generic/388: randomly recover via read-only mounts
Date: Tue, 5 Jan 2021 06:54:20 -0500	[thread overview]
Message-ID: <20210105115420.GA286564@bfoster> (raw)
In-Reply-To: <20210104183424.GA6919@magnolia>

On Mon, Jan 04, 2021 at 10:34:24AM -0800, Darrick J. Wong wrote:
> On Thu, Dec 17, 2020 at 09:59:41AM -0500, Brian Foster wrote:
> > XFS has an issue where superblock counters may not be properly
> > synced when recovery occurs via a read-only mount. This causes the
> > filesystem to become inconsistent after unmount. To cover this test
> > case, update generic/388 to switch between read-only and read-write
> > mounts to perform log recovery.
> > 
> > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > ---
> > 
> > I didn't think it was worth duplicating generic/388 to a whole new test
> > just to invoke log recovery from a read-only mount. generic/388 is a
> > rather general log recovery test and this preserves historical behavior
> > of the test.
> > 
> > A prospective fix for the issue this reproduces on XFS is posted here:
> > 
> > https://lore.kernel.org/linux-xfs/20201217145334.2512475-1-bfoster@redhat.com/
> > 
> > Brian
> > 
> >  tests/generic/388 | 10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tests/generic/388 b/tests/generic/388
> > index 451a6be2..cdd547f4 100755
> > --- a/tests/generic/388
> > +++ b/tests/generic/388
> > @@ -66,8 +66,14 @@ for i in $(seq 1 $((50 * TIME_FACTOR)) ); do
> >  		ps -e | grep fsstress > /dev/null 2>&1
> >  	done
> >  
> > -	# quit if mount fails so we don't shutdown the host fs
> > -	_scratch_cycle_mount || _fail "cycle mount failed"
> > +	# Toggle between rw and ro mounts for recovery. Quit if any mount
> > +	# attempt fails so we don't shutdown the host fs.
> > +	if [ $((RANDOM % 2)) -eq 0 ]; then
> > +		_scratch_cycle_mount || _fail "cycle mount failed"
> > +	else
> > +		_scratch_cycle_mount "ro" || _fail "cycle ro mount failed"
> > +		_scratch_cycle_mount || _fail "cycle mount failed"
> 
> I would change that third failure message to something distinct, like:
> 
> _fail "cycle remount failed"
> 
> To give us extra clues as to which branch encountered failure.
> This looks like a fun way to find new bugs. :)
> 

Sure.. I tweaked it to "cycle rw mount failed" so it's distinct, yet
more consistent with the preceding ro cycle.

Brian

> --D
> 
> > +	fi
> >  done
> >  
> >  # success, all done
> > -- 
> > 2.26.2
> > 
> 


      reply	other threads:[~2021-01-05 11:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17 14:59 [PATCH] generic/388: randomly recover via read-only mounts Brian Foster
2021-01-04 18:34 ` Darrick J. Wong
2021-01-05 11:54   ` Brian Foster [this message]

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=20210105115420.GA286564@bfoster \
    --to=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.