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@xxxxxxxxxx>
> > 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...