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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox