All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Ben Myers <bpm@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 3/3] xfs: prevent needless mount warning causing test failures
Date: Wed, 9 May 2012 08:42:24 +1000	[thread overview]
Message-ID: <20120508224224.GJ5091@dastard> (raw)
In-Reply-To: <20120508162942.GK16881@sgi.com>

On Tue, May 08, 2012 at 11:29:42AM -0500, Ben Myers wrote:
> On Fri, Apr 27, 2012 at 07:45:22PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > Often mounting small filesystem with small logs will emit a warning
> > such as:
> > 
> > XFS (vdb): Invalid block length (0x2000) for buffer
> > 
> > during log recovery. This causes tests to randomly fail because this
> > output causes the clean filesystem checks on test completion to
> > think the filesystem is inconsistent.
> > 
> > The cause of the error is simply that log recovery is asking for a
> > buffer size that is larger than the log when zeroing the tail. This
> > is because the buffer size is rounded up, and if the right head and
> > tail conditions exist then the buffer size can be larger than the log.
> > Limit the variable size xlog_get_bp() callers to requesting buffers
> > smaller than the log.
> > 
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > ---
> >  fs/xfs/xfs_log_recover.c |    4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> > index d7abe5f..ca38690 100644
> > --- a/fs/xfs/xfs_log_recover.c
> > +++ b/fs/xfs/xfs_log_recover.c
> > @@ -441,6 +441,8 @@ xlog_find_verify_cycle(
> >  	 * a log sector, or we're out of luck.
> >  	 */
> >  	bufblks = 1 << ffs(nbblks);
> > +	while (bufblks > log->l_logBBsize)
> > +		bufblks >>= 1;
> 
> AFAICS you don't need a loop here.  The following would be sufficient to make
> xlog_buf_bbcount_valid return 0. 
> 
> if (bufblks > log->l_logBBsize)
> 	bufblks = log->l_logBBsize;

Yes, I could do that, but then there is a different set of boundary
conditions to test. I know that the >>=1 logic works, but I have no
idea what new corner cases occur when bufblks == log->l_logBBsize.

> It is a bit more obviously correct.

It may be to read, but it's certainly more different from a
verification point of view. Given how long and arduous the process
was to find the source of the problem, I am very wary of changing
logic to run in ways that are different and very difficult to
actually test....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-05-08 22:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-27  9:45 [PATCH 0/3] xfs: failed writes and stale delalloc blocks Dave Chinner
2012-04-27  9:45 ` [PATCH 1/3] xfs: punch all delalloc blocks beyond EOF on write failure Dave Chinner
2012-04-30 13:49   ` Christoph Hellwig
2012-04-27  9:45 ` [PATCH 2/3] xfs: punch new delalloc blocks out of failed writes inside EOF Dave Chinner
2012-05-07 22:00   ` Ben Myers
2012-04-27  9:45 ` [PATCH 3/3] xfs: prevent needless mount warning causing test failures Dave Chinner
2012-05-08 16:29   ` Ben Myers
2012-05-08 22:42     ` Dave Chinner [this message]
2012-04-29 11:16 ` [PATCH 4/3] xfs: don't assert on delalloc regions beyond EOF Dave Chinner
2012-05-08 17:26   ` Ben Myers
2012-04-29 12:43 ` [PATCH 5/3] xfs: limit specualtive delalloc to maxioffset Dave Chinner
2012-05-08 18:02   ` Ben Myers
2012-04-29 12:57 ` [PATCH 6/3] xfs: make largest supported offset less shouty Dave Chinner
2012-04-29 21:58   ` Christoph Hellwig
2012-04-30  1:11     ` Dave Chinner
2012-04-30  3:03       ` Dave Chinner
2012-05-08 18:15   ` Ben Myers
2012-05-08 22:43     ` Dave Chinner
2012-05-09 19:14       ` Ben Myers

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=20120508224224.GJ5091@dastard \
    --to=david@fromorbit.com \
    --cc=bpm@sgi.com \
    --cc=xfs@oss.sgi.com \
    /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.