From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/2] xfs: ensure we copy buffer type in da btree root splits
Date: Mon, 2 Sep 2013 20:09:30 +1000 [thread overview]
Message-ID: <20130902100930.GD12779@dastard> (raw)
In-Reply-To: <20130902081725.GB11210@infradead.org>
On Mon, Sep 02, 2013 at 01:17:25AM -0700, Christoph Hellwig wrote:
> On Mon, Sep 02, 2013 at 10:32:01AM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > When splitting the root of the da btree, we shuffled data between
> > buffers and the structures that track them. At one point, we copy
> > data and state from one buffer to another, including the ops
> > aasociated with the buffer. When we do this, we also need to copy
> > the buffer type associated with the buf log item so that the buffer
> > is logged correctly. If we don't do that, log recovery won't
> > recognise it and hence it won't recalculate the CRC on the buffer
> > after recovery. This leads to a directory block that can't be read
> > after recovery has run.
> >
> > Found by inspection after finding the same problem with remote
> > symlink buffers.
>
> It would be great to find a way to trigger this in QA as this shows
> another area lacking coverage.
I'm pretty sure the same script I discovered the symlink problem was
triggering it. It was actually trying to track down an
assert failure in the directory code that Michael Semon had reported
to me with a rough test case that I then scripted.
I just haven't done enough testing to be certain it wasn't something
else. Also, xfs/182 was assert failures after log recovery that had
a similar signature that I also haven't seen since adding this
patch. So I think we got some coverage of it...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-09-02 10:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-02 0:31 [PATCH 0/2] xfs: log recovery buffer fixes Dave Chinner
2013-09-02 0:32 ` [PATCH 1/2] xfs: set remote symlink buffer type for recovery Dave Chinner
2013-09-02 8:16 ` Christoph Hellwig
2013-09-02 10:05 ` Dave Chinner
2013-09-02 0:32 ` [PATCH 2/2] xfs: ensure we copy buffer type in da btree root splits Dave Chinner
2013-09-02 8:17 ` Christoph Hellwig
2013-09-02 10:09 ` Dave Chinner [this message]
2013-09-10 22:41 ` [PATCH 0/2] xfs: log recovery buffer fixes 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=20130902100930.GD12779@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--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.